非交互式 SSH 密码认证

原文 ↗ Hacker News 讨论 ↗

自动化需要密码的 SSH 连接仍然颇具争议：一些工程师乐于依赖 `sshpass` 之类的工具，而另一些人则认为这些方法很脆弱，因为它们依赖于解析提示信息和不稳定的 TTY 行为。许多参与者坚持认为，公钥或证书认证、Kerberos，或者短期 SSH 证书更安全、也更具可扩展性，但也承认旧式网络设备、TACACS/RADIUS 配置以及厂商限制，常常使得仅能使用密码的 SSH 成为唯一可行方案。讨论进一步延伸到如何在大规模场景下管理特权访问——通过配置管理、PAM 产品、堡垒机或自定义代理——并强调在真实基础设施中，安全性、复杂性与可靠性之间的权衡。

非交互式 SSH 密码认证方法

  • 许多评论者认为应避免将密码认证用于 SSH；更偏好密钥/证书，且有些人甚至完全禁用密码登录。
  • 也有人指出，在某些网络设备、BMC、厂商盒子、TACACS+/RADIUS 环境，或仅能使用密码的初始配置阶段，非交互式密码认证不可避免。
  • 一些人正在探索自动化基于 OTP/TOTP 的 SSH，但并未给出具体、稳健的方案。

sshpass 与替代方案（passh、ASKPASS、expect）

  • 不少人表示 sshpass “足够好”，并引用了大规模使用（数万台机器）而无问题的经验，称赞其简单性。
  • 批评者指出 sshpass 很脆弱，因为它需要解析密码提示；提示内容或 TTY 行为的变化都可能导致它失效。
  • 一种替代模式是使用 SSH_ASKPASS 和 SSH_ASKPASS_REQUIRE（在较新的 OpenSSH 客户端中）以更可控的方式注入密码，可能使额外工具更简单，甚至不再需要。
  • passh 工具被提及在 TTY 处理方面更稳健；对 sshpass “按设计就是坏的”这一指责来自该项目，而非本文作者。
  • 传统工具如 expect 也被提到；它们很强大，但也可能很脆弱，尤其是在 cron 中或没有真实 TTY 时。

密钥、证书与现实约束

  • 评论者再次强调密钥/证书才是“正确方式”，但也描述了阻碍：
    • 网络设备（例如某些 Cisco/Juniper 变种、Ubiquiti 设备）上，密钥配置很麻烦或不具持久性。
    • 通过 TACACS+/RADIUS 的集中认证往往围绕密码设计，对密钥的支持有限或较为临时。
    • 许多嵌入式 SSH 栈缺少 FIDO2 之类的现代特性。
  • 有人建议使用 SSH 证书、Kerberos 或 FreeIPA，但也承认其运维和组织上的复杂性。

TTY、脚本与稳健性

  • 有多则关于 cron 作业、sftp，以及在没有控制 TTY 时表现不同的工具的经验分享。
  • 变通办法包括 script、screen、ssh -t、Paramiko，以及用 rsync 代替 sftp。
  • 对于 TTY//proc 解析和 shell 脚本到底是“只要读手册就很简单”，还是本质上就充满坑点，存在争论；有人提到了“最少惊讶原则”。

特权访问与更高层方案

  • 有人主张使用特权访问管理系统、堡垒机、与用户关联的 VPN，或短期 SSH 证书（例如通过 Vault/Teleport）来避免嵌入密码。
  • 也有人提醒，这些产品本身可能成为高价值且脆弱的目标，而良好的 IAM/PAM 设计可能比再加一层代理更重要。