ssh连接超时需按四类路径排查：1.网络链路（ping/nc/traceroute/iptables）；2.目标主机ssh服务（sshd状态、sshd_config配置、auth.log日志、authorized_keys权限）；3.ansible配置（timeout值、私钥路径、用户身份、host_key_checking）；4.目标主机资源（cpu/内存负载、sshd进程状态、maxstartups限制）。
排查 SSH 连接超时的四个关键路径
Ansible 报 Failed to connect to the host via ssh，不等于网络不通，也不一定是密码错了——它只是 SSH 建连失败的笼统提示。真正原因藏在四类位置：网络链路、目标主机 SSH 服务、Ansible 自身配置、目标主机资源状态。挨个验证比盲改配置更省时间。
检查网络可达性与防火墙策略
先确认基础通路是否成立，避免在上层配置里兜圈子：
-
ping -c 4：丢包率 >5% 就不能信，得查中间设备或路由抖动 -
nc -zv 22或telnet 22：绕过 SSH 协议，直测端口是否开放、可响应 -
iptables -L -n | grep :22（目标主机执行）：确认没被 INPUT 链 DROP，尤其注意REJECT和DROP的区别 -
traceroute：某跳延迟突增或中断，说明是网络路径问题，不是 Ansible 或 SSH 配置问题
验证目标主机 SSH 服务与密钥配置
很多“超时”其实是 SSH 服务拒绝握手，但错误日志被 Ansible 截断了。登录目标主机看真实原因：
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
-
systemctl status sshd：确保服务 running，且没卡在 reload 状态 -
grep -E "^(Port|PermitRootLogin|PasswordAuthentication|AuthorizedKeysFile)" /etc/ssh/sshd_config：重点核对AuthorizedKeysFile路径是否拼错（比如写成authorized_key少了个s），这个错会导致 SSH 进程静默拒绝连接 -
tail -n 20 /var/log/auth.log | grep sshd：找Connection closed by remote host或invalid format类提示，比 Ansible 的UNREACHABLE!更准 -
ls -l ~/.ssh/authorized_keys：权限必须是600，目录700；SELinux 启用时还要确认上下文：ls -Z ~/.ssh/authorized_keys
检查 Ansible 连接参数与身份文件
Ansible 默认只给 10 秒建连时间，又默认尝试一堆密钥文件，容易在中间环节卡死：
-
timeout值太小：在ansible.cfg中设[defaults] timeout = 30，别依赖默认值 - 指定错误的私钥：
ansible -vvv日志里会打印类似IdentityFile="/root/.ssh/id_rsa.bak"的行——如果该文件不存在，就会报no such identity，而不是超时；删掉 inventory 或 config 里多余的ansible_ssh_private_key_file配置项 - 中控机用户不对：Jenkins 或 systemd 服务以
tomcat用户跑 Ansible 时，它读的是/home/tomcat/.ssh/，不是 root 的密钥；要么给 tomcat 配密钥，要么加sudo -u root ansible ... - 禁用
host_key_checking：首次连接未录入指纹时，Ansible 会卡住等待交互，需在ansible.cfg中设host_key_checking = False
观察目标主机负载与 SSH 进程状态
高负载下 SSH daemon 可能无法及时 accept 新连接，表现为“超时”，但 ping 和 nc 都通：
-
top -b -n 1 | head -10：CPU 使用率持续 >80%，或内存%MEM列接近 100%，就可能拖慢 SSH handshake -
ss -tnp | grep :22：看LISTEN状态的 sshd 进程是否存在，以及SYN-RECV连接数是否堆积（说明连接请求进来了但没被处理） -
journalctl -u sshd --since "2 hours ago" | grep -i "refused\|limit\|fork"：SSH daemon 主动拒绝连接时，常带fork failed或max startups提示
这类问题往往只在批量执行时爆发，单台测试正常，所以压测前务必检查目标节点的资源水位和 MaxStartups 配置。
