SSH 连不上服务器，应该从哪里开始排查？

SSH 失败时，终端里往往只有一句模糊的报错。真正有效的办法，不是把网上搜到的命令全部试一遍，而是先判断故障发生在哪一层。

先记住这条顺序

IP 能否到达 → 端口是否开放 → 服务是否运行 → 身份认证是否通过

第一步：确认网络能到达

先从最基础的连通性开始。确认服务器 IP 没写错、本机网络正常，再检查中间是否经过 VPN、旁路由或安全组。

可以先尝试：

ping 192.168.1.20

图 1：把连接路径拆开，逐段排除故障。

能 ping 通不代表 SSH 一定可用，但完全无法到达 IP 时，继续修改 SSH 配置通常没有意义。如果服务器禁用了 ICMP，也可以跳过 ping，直接检查 TCP 端口。

第二步：确认 SSH 服务端口

如果网络正常，接下来检查目标端口是否能建立连接：

nc -vz 192.168.1.20 22

出现 succeeded 说明端口可以访问；如果超时，优先检查云服务器安全组、主机防火墙以及路由器的端口映射。

图 2：成功建立到 22 端口的 TCP 连接。

如果返回 Connection refused，通常代表主机能够到达，但对应端口没有服务监听，或者服务被主机主动拒绝。

第三步：查看认证日志

端口能通却登录失败，问题通常已经缩小到账号、密钥或服务端认证策略。此时日志比猜测可靠。

1. 确认用户名：云服务器经常使用 ubuntu、debian 或 ec2-user，而不是 root。
2. 确认密钥：检查本地私钥是否对应服务器 authorized_keys 中的公钥。
3. 检查权限：私钥、.ssh 目录和 authorized_keys 权限过宽时，SSH 会拒绝使用。
4. 读取日志：Debian/Ubuntu 查看 auth.log，使用 systemd 的系统也可以查看 ssh 服务日志。

验证标准

重新连接后能进入 Shell，并且服务端日志中不再出现认证错误。