不少同行在自动化运维实践中，都会遇到这样一个场景：需要批量修改几十甚至上百台服务器的登录密码。用paramiko写个脚本看起来顺理成章，但真动手时才发现，坑比想象中深。
用 paramiko 批量改密码前，先确认目标主机是否支持 SSH 密码修改
大多数 Linux 主机默认不允许直接通过 SSH 会话执行 passwd 命令来非交互式改密——因为 passwd 会读取终端（tty）并要求输入旧密码、新密码两次，而 paramiko 的 exec_command() 默认不分配伪终端（pty），直接运行会卡住或报错 passwd: Authentication token manipulation error。
要解决这个问题，通常有两条路，但每条都有明显的短板：
- 在目标主机上启用
sudo passwd $USER免密（需提前配置/etc/sudoers，风险高，不推荐） - 改用
ssh+expect脚本（本地需装expect，跨平台性差） - 更稳妥的做法：用
paramiko开启 pty 并手动模拟交互流，逐行发送密码
用 paramiko 的 invoke_shell() 模拟真实终端交互
exec_command() 适合执行无交互命令，比如查个系统版本、读个配置文件，都没问题。但改密码这种需要你来我往的对话场景，必须用 invoke_shell() 获取交互式 shell，再用 send() 和 recv() 控制流程。关键点在于等待提示符、识别错误输出、控制换行和延时。
以修改当前用户密码为例，典型的交互序列看起来很简单：
立即学习“Python免费学习笔记（深入）”；
stdin.send('passwd\n')
stdin.send('old_password\n')
stdin.send('new_password\n')
stdin.send('new_password\n')
但实际落地时，需要处理的细节远比这段代码看起来复杂：
- 不同系统提示符不同（
$、#、[user@host ~]$），建议用正则匹配r'[\$#] $' - 部分主机首次登录会提示
The authenticity of host ... can't be verified，需提前用ssh-keyscan或设置AutoAddPolicy - 密码含特殊字符（如
$、\n）要转义或用 raw 字符串 - 每次
send()后必须recv()等待响应，不能连续发——否则命令会乱序或丢弃
生成报表时别只写成功/失败，得记录真实执行上下文
单纯记 "192.168.1.10: success" 没什么用处。出问题时你根本不知道是连不上、权限不足、还是密码策略拒绝了新密码。
建议每台主机至少记录以下字段到 CSV 或 JSON：
host、port、usernamestatus（connected/auth_failed/passwd_failed/timeout）error_message（截取最后 200 字节的stderr或交互日志）start_time、end_time（用于排查慢主机）new_password_hash（可选，SHA256(主机名+时间戳+salt)，避免明文落盘）
需要注意的是：open('report.csv', 'a') 在多线程写入时会乱序，必须加锁或用单线程顺序执行。批量改密本身就不适合并发过高，10 台以内建议串行，避免触发目标主机的 SSH 登录限速（如 MaxStartups）。
真正落地前，先用一台机器做「最小闭环验证」
千万不要一上来就跑 50 台。先拿一台测试机，手动执行一遍你要自动化的完整路径：
- SSH 连上去，手工跑
passwd，看提示怎么问、输几次、回显什么 - 用 Python +
paramiko连同一台，只做invoke_shell()+send('whoami\n')，确认基础连接和 recv 逻辑通 - 再加入
passwd流程，打印每一行recv()结果，观察哪一步卡住 - 最后加上报表写入，验证字段是否齐全、编码是否正常（尤其中文主机名或错误信息）
很多失败并不是代码层面的问题，而是目标主机的 PAM 配置、SELinux 策略、或者密码复杂度规则（比如要求包含大小写字母+数字+符号）没有被脚本感知——这些只能靠真实交互日志来暴露。
