Ansible通过SSH连接失败（Banner交换超时）求助

算力阿峰

2026-5-21

看到你遇到Ansible在SSH Banner Exchange阶段超时的问题，我整理了几个从基础到进阶的排查方向，你可以一步步来试：

1. 先排除基础网络和直接SSH的问题

先绕开Ansible，直接测试底层的SSH连通性，定位问题到底在网络还是Ansible配置：

直接执行ssh remote@192.xxx.xxx.xxx，看看是不是同样出现超时。如果直接SSH也失败，那问题根源不在Ansible，先解决网络或目标主机的SSH服务问题。
用ping 192.xxx.xxx.xxx确认目标主机在线且网络可达。如果ping不通，检查：
- 目标主机是否开机运行
- 本地/目标主机的防火墙是否拦截了ICMP包
- 路由是否正常（比如跨网段的话，网关配置是否正确）
用telnet 192.xxx.xxx.xxx 22测试SSH端口（22）是否开放。如果连不上，说明22端口被拦截：
- 检查目标主机的防火墙（比如ufw status或者iptables -L），确认允许22端口的入站请求
- 如果你用的是云服务器，检查云服务商的安全组规则，确保22端口对你的IP开放

如果telnet能通但SSH/Ansible超时，重点排查目标主机的sshd配置：

先确认sshd服务在运行：在目标主机执行systemctl status sshd（Systemd系统）或service ssh status（SysVinit系统），如果服务没启动，先启动它systemctl start sshd。
打开目标主机的/etc/ssh/sshd_config文件，检查几个关键参数：
- Banner：如果配置了自定义Banner（比如Banner /etc/ssh/banner.txt），确认这个文件存在、权限正确（至少sshd进程能读取，比如chmod 644 /etc/ssh/banner.txt）。如果Banner文件损坏或无法读取，会导致Banner交换阶段卡住超时。
- LoginGraceTime：这个参数控制SSH连接的超时等待时间，默认可能是120秒，但如果网络较慢或目标主机负载高，可能需要调大（比如改成LoginGraceTime 180），修改后重启sshd：systemctl restart sshd。
- MaxStartups：如果这个值设置得太低，当同时有大量连接请求时，新连接会被拒绝或超时。可以临时调高测试，比如MaxStartups 10:30:100。

如果直接SSH能成功，但Ansible失败，那问题可能在Ansible的配置：

增加Ansible的连接超时时间，执行命令时加上-T参数：
```
ansible all -m ping -u remote 192.xxx.xxx.xxx -T 30
```
这里把超时时间设为30秒，比默认的10秒更长，看看是不是超时时间太短导致的。
检查Ansible的配置文件（~/.ansible.cfg或/etc/ansible/ansible.cfg），看看ssh_args有没有配置影响连接的参数。比如如果开启了ControlPersist但时间过长，可能导致旧连接残留，临时注释掉相关配置再测试。
确认密钥登录的配置：如果你用密钥登录，检查本地私钥的权限（必须是600，执行chmod 600 ~/.ssh/id_rsa），同时确认目标主机~remote/.ssh/authorized_keys里已经正确添加了你的公钥，且文件权限是600、目录权限是700。

目标主机负载过高：如果目标主机CPU、内存占用100%，sshd进程可能无法及时响应连接请求。如果能通过其他方式登录目标主机，用top或htop查看资源使用情况，清理占用资源的进程。
代理或VPN干扰：如果你本地或目标主机使用了代理、VPN，可能会影响SSH连接。试试关闭代理后再测试Ansible命令。
SSH算法兼容性：如果本地OpenSSH版本和目标主机版本差异过大，可能存在密钥交换算法不兼容的问题。可以在Ansible命令里指定兼容的算法测试：
```
ansible all -m ping -u remote 192.xxx.xxx.xxx -e ansible_ssh_extra_args="-o KexAlgorithms=diffie-hellman-group1-sha1"
```
注意：这个算法安全性较低，仅用于测试，不要长期使用。

内容的提问来源于stack exchange，提问作者Atik