sshpass非交互式ssh认证及自动化操作

Posted on Views:

在自动化场景里，sshpass 是个“权宜之计”的小工具，用来在没有交互的情况下把密码塞给 ssh/scp/rsync。它的核心作用，就是绕过交互式的 Password: 提示，将密码直接通过非交互方式提供给 SSH 客户端。这在严格安全体系里不优雅，但在自动化脚本、一次性批量操作、无密钥环境的旧机器里，确实能救急。

应用场景

1.无密钥但需要批量执行命令

比如某些历史包袱较重的老机器，还没上 key 登录，也不太可能短期整改，这类临时批量执行命令，经常就靠 sshpass：

1
sshpass -p "123456" ssh -o StrictHostKeyChecking=no root@10.0.0.1 "uptime"

2.批量 SCP 文件分发

运维常会遇到“几十台临时机器，急着分发配置”的情况。没有 key 的话，只能硬着头皮用 sshpass 来批处理：

1
sshpass -p "123456" scp -o StrictHostKeyChecking=no file.cfg root@10.0.0.2:/etc/app/

3.自动化脚本 CI/CD 场景

某些 CI 工具（老平台）执行部署脚本时，没有提供密钥管理能力，又需要把文件推到某个测试机，这时 sshpass 能让脚本实现完全无人值守：

1
sshpass -p "$SERVER_PASS" rsync -avz ./dist/ root@server:/data/app/

4.初始化阶段的快速接入环节

一些批量接入脚本（初始化 OS、替换包管理源、安装 agent），在“第一阶段”需要使用默认密码登录机器，随后才会创建密钥并删除密码登录sshpass 常用于这个短暂阶段。

安全角度提醒

1.sshpass 本质上是明文密码暴露工具

密码要么写在命令行，要么写在环境变量，要么写在文件里。都不是安全最佳实践。从安全角度看，它更像是“迁移到更安全方案前的过渡期工具”。

2.推荐的长期替代方案

前瞻性来看，自动化和 DevOps 系统应该切到：

  • SSH 公钥（key）认证
  • Kerberos / GSSAPI
  • Vault + 动态密钥
  • 跳板机（Bastion）+ 临时授权
  • 基于 GitOps/Agent 的下发模式，而不是 SSH 推送

这些方案更稳定、更可控、更可审计。

4.架构视角下sshpass

flowchart LR
    A[自动化脚本/CI] --> B{是否有SSH密钥?}
    B -- 是 --> C[正常 ssh/scp/rsync]
    B -- 否 --> D[使用 sshpass 提供密码]
    D --> E[执行 ssh/scp/rsync]
    E --> F[完成或后续生成密钥]

这种结构体现了 sshpass 经常是应急入口、初始化入口的角色，而不是长期解决方案。跨过去，也就跨向一个更稳健、更舒展的自动化体系。