Non-interactive SSH password authentication

Original Article ↗ Hacker News Discussion ↗

Automating SSH connections that require passwords remains contentious, with some engineers happily relying on tools like `sshpass` while others argue these approaches are brittle because they depend on parsing prompts and fragile TTY behavior. Many participants insist that public key or certificate-based authentication, Kerberos, or short‑lived SSH certificates are safer and more scalable, but acknowledge that legacy network gear, TACACS/RADIUS setups, and vendor constraints often leave password-only SSH as the only practical option. The conversation broadens into how to manage privileged access at scale—via configuration management, PAM products, bastion hosts, or custom agents—highlighting the trade‑offs between security, complexity, and reliability in real-world infrastructures.

Non-interactive SSH password auth approaches

  • Many commenters argue that password auth for SSH should be avoided; keys/certificates are preferred, and some disable password logins entirely.
  • Others note non-interactive password auth is unavoidable with certain network devices, BMCs, vendor boxes, TACACS+/RADIUS setups, or initial provisioning where only passwords are available.
  • Some are exploring automating OTP/TOTP-based SSH, but concrete, robust recipes are not detailed.

sshpass vs alternatives (passh, ASKPASS, expect)

  • Several people say sshpass is “good enough”, citing large-scale use (tens of thousands of machines) without issues and praising its simplicity.
  • Critics point out sshpass is brittle because it parses password prompts; changes in prompts or TTY behavior can break it.
  • An alternative pattern is to use SSH_ASKPASS and SSH_ASKPASS_REQUIRE (in newer OpenSSH clients) to inject passwords in a more controlled way, possibly making extra tools simpler or unnecessary.
  • The passh tool is referenced as more robust around TTY handling; the “broken by design” accusation of sshpass comes from that project, not from the article’s author.
  • Traditional tools like expect are mentioned; they’re powerful but can be fragile, especially under cron or without a real TTY.

Keys, certificates, and real-world constraints

  • Commenters reiterate that keys/certs are “the right way” but describe obstacles:
    • Network gear (e.g., some Cisco/Juniper variants, Ubiquiti devices) where key setup is awkward or non-persistent.
    • Central auth via TACACS+/RADIUS often designed around passwords, with limited or ad‑hoc key support.
    • Many embedded SSH stacks lack modern features like FIDO2.
  • Some suggest SSH certificates, Kerberos, or FreeIPA, but acknowledge operational and organizational complexity.

TTY, scripting, and robustness

  • Multiple war stories about cron jobs, sftp, and tools that behave differently without a controlling TTY.
  • Workarounds include script, screen, ssh -t, Paramiko, and rsync instead of sftp.
  • There is debate over whether TTY//proc parsing and shell scripting are “trivial if you read the manual” vs. inherently full of footguns; the principle of least astonishment is raised.

Privileged access & higher-level solutions

  • Some advocate privileged access management systems, bastions, user-associated VPNs, or short‑lived SSH certs (e.g., via Vault/Teleport) to avoid embedding passwords at all.
  • Others caution that these products can themselves be high‑value, fragile targets, and that good IAM/PAM design may be more important than adding another proxy layer.