SSH 连不上时，先分清 refused 和 timed out

SSH 连不上，报错通常只有一句：connect to host x.x.x.x port 22: Connection timed out，或者 Connection refused。这两句指向的方向完全不同，先分清再动手，能省掉一半无用功。

先区分 refused 和 timed out

Connection refused 说明包到了机器，只是 22 端口上没有进程在听。常见原因是 sshd 没起来，或者只监听了内网地址。这时候上机器（云主机用控制台 VNC 或者带外通道）看两件事：

ss -lntp | grep ':22'
systemctl status sshd

第一条如果显示 127.0.0.1:22 而不是 0.0.0.0:22，说明配置里 ListenAddress 写死了本地回环。第二条如果是 failed，先看日志：

journalctl -u sshd -n 50

权限问题（/etc/ssh 下私钥属主或 600 权限不对）和配置语法错误都会在这里露出来。

Connection timed out 是包根本没到，按从外到内的顺序查：安全组或防火墙有没有放行 22、路由对不对、机器本身是否还在运行。云上最常见的漏点是安全组入方向只放行了 ICMP 却没放 22，ping 得通但 SSH 一片死寂，很容易误判成网络问题。

连上了但卡在认证

还有一类不在这两句里：TCP 通了，认证过不去。ssh -v 会把协商过程逐行打出来。卡在 Offering public key 后面长时间不动的情况，遇到过两种原因——服务端做了反向 DNS 查询而 DNS 不通，以及 PAM 里的失败计数模块（pam_tally2、pam_faillock）因为之前的密码错误把账号锁了。后者在服务端日志里能看到 failed logins 一类的内容。

这类问题只看客户端输出判断不了，必须两边对着看。

顺序上的取舍

排查成本是递增的：改安全组要进控制台点，看 sshd 状态要另开一条通道登进去，认证问题往往只能靠日志。所以先确认端口有没有到、再看监听、最后看认证，前两步能排除掉大部分情况。

一个容易忽略的点：不要只看客户端报错就下结论。同样是「连不上」，客户端显示的是超时，服务端可能已经收到了失败握手并记了日志，两边的信息拼起来才是完整的。