SSH 连不上服务器，先按这三层排查

SSH 连不上，是运维里最常见的故障之一。报错信息五花八门：Connection timed out、Connection refused、Permission denied、主机密钥校验失败……但排查其实有固定顺序：先网络通不通，再服务在不在，最后才是认证对不对。按这个顺序走，大多数问题十分钟内就能定位。

第一层：网络通不通

先确认本机到服务器的路是不是通的。

最常用的是 ping，但要注意：很多云服务器默认禁 ping，ping 不通不代表网络不通。更可靠的是直接测端口：

telnet <服务器IP> 22

或者用 nc -vz <服务器IP> 22。如果 telnet 长时间无响应，最后报 Connection timed out，问题大概率在网络层：安全组没放行 22 端口、服务器防火墙拦截、本地网络或代理阻断、甚至是服务器关机了。

这一步还有个容易被忽略的点：确认你连的是对的 IP 和端口。云服务器换过弹性 IP、SSH 改过默认端口，都是真实发生过的“乌龙”。先把目标地址核对一遍，再往下查。

如果端口能通，telnet 会立刻返回类似 SSH-2.0-OpenSSH_8.9 的横幅，说明网络层没问题，进入下一层。

第二层：服务在不在

端口通了，不等于 sshd 在正常工作。Connection refused（连接被拒绝）通常就是这一层的信号：网络到了，但 22 端口上没有程序在监听。

常见原因有三个：

1. sshd 没启动或崩了。服务器重启后 sshd 未自启，或者配置改错导致启动失败。这时需要通过云厂商的控制台（VNC 或串口）登上机器，跑 systemctl status sshd 看状态，systemctl restart sshd 重启服务。
2. sshd 监听地址或端口配错了。比如配置文件里 Port 改成了 2222，但你还在连 22。检查 /etc/ssh/sshd_config 里的 Port 和 ListenAddress。
3. 系统资源耗尽。内存或磁盘满了，sshd 无法 fork 新进程，连接会被直接拒绝。这种情况先清磁盘、释放内存。

注意：这一层的排查往往需要另一条“后门”通道，比如云控制台的 VNC。平时就把这条通道准备好，等真出问题时才不会抓瞎。

第三层：认证对不对

网络通了、服务在了，连接却在输入密码或密钥后被拒，问题在认证层。

密码登录被拒：先确认账号是否被锁定（passwd -S 用户名）、密码是否过期、sshd 配置是否允许密码登录（PasswordAuthentication yes）。云服务器上还常见一种情况：root 被禁密码登录（PermitRootLogin prohibit-password），用 root 密码连永远被拒，改用普通用户加 sudo 才是正途。

密钥登录被拒：排查点更具体。Permission denied (publickey) 出现时，依次检查：

• 本地私钥文件权限是不是 600，太松会被 sshd 直接拒绝；
• 服务器上 ~/.ssh/authorized_keys 里有没有这把公钥，内容是否完整、有没有多余换行；
• .ssh 目录权限是不是 700，authorized_keys 是不是 600，属主对不对；
• sshd_config 里 PubkeyAuthentication 是不是 yes。

用 ssh -v 看详细日志是最快的办法。日志里会明确写出尝试了哪些认证方式、哪一步失败，比猜要可靠得多。

主机密钥校验失败：WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED 表示服务器的主机密钥变了，通常是服务器重装或 IP 被复用。确认是自己操作的重装后，用 ssh-keygen -R <服务器IP> 清掉旧记录再连。注意：没确认原因之前不要随手清掉警告，它是防中间人攻击的最后一道防线。

一个实用的排查顺序

总结成一张检查单：

1. telnet IP 22 —— 超时是网络层，查安全组和防火墙；
2. 拒绝连接是服务层，查 sshd 状态和监听端口；
3. 认证失败是认证层，ssh -v 看日志，对照账号、密钥、权限逐项核对。

很多时候故障并不复杂，复杂的是慌乱中东试西试、把问题越搅越乱。先分清卡在哪一层，再在那一层里找原因，是排查 SSH 问题的最短路径。

平时还可以做两件事防患于未然：一是给服务器留一条云控制台 VNC 通道，二是把常用服务器的 IP、端口、登录方式记在一个自己能随时找到的地方。出问题时，这两样东西能帮你省下大半时间。