SSH 突然无法连接：从网络、端口、服务到密钥认证的系统排查

SSH 失联可能发生在 DNS、路由、防火墙、安全组、sshd 服务、连接数、认证策略或客户端代理任一环节。先根据错误信息判断故障阶段，再逐层排查，比反复更换密钥更有效。

一、先识别客户端错误

ssh -vvv -o ConnectTimeout=8 user@host

• Connection timed out：网络路径、ACL、安全组或端口未响应；

• Connection refused：主机可达，但端口未监听或被主动拒绝；

• No route to host：路由、网关或防火墙返回不可达；

• Permission denied：已经到达认证阶段，重点检查用户、密钥和策略；

• 连接建立后立即关闭：检查 sshd 日志、用户 Shell、PAM 和资源限制。

二、检查 DNS 与网络路径

getent hosts hostname
ping -c 3 host
traceroute host
nc -vz -w 5 host 22

不要只依赖 ping，很多环境禁用 ICMP。nc 或 Test-NetConnection 更适合确认目标端口。如果使用域名，应比较 DNS 结果与云主机实际公网 IP，避免旧解析或代理地址干扰。

三、检查云安全组和主机防火墙

确认云安全组、网络 ACL、堡垒机策略和本机防火墙都允许正确源地址访问 SSH 端口。

sudo nft list ruleset
sudo iptables -S
sudo firewall-cmd --list-all
sudo ufw status verbose

同时检查 Fail2ban、DenyHosts 或安全设备是否封禁客户端地址。

四、通过控制台检查 sshd

无法远程连接时，应使用云控制台、虚拟机控制台或带外管理进入系统：

systemctl status ssh sshd
ss -lntp | grep -E ':22\b'
sshd -t
journalctl -u ssh -u sshd --since '-30 minutes'

修改配置后先执行 sshd -t，确认语法正确再 reload，避免把自己锁在门外。

五、检查密钥认证

namei -l ~/.ssh/authorized_keys
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

常见建议权限为：用户主目录不可被其他用户写入，.ssh 为 700，authorized_keys 为 600，并且所有者正确。还要检查公钥是否完整、登录用户名是否正确，以及 AllowUsers、DenyUsers、AuthenticationMethods 等策略。

SELinux 环境可执行：

restorecon -Rv ~/.ssh
ausearch -m AVC -ts recent

六、检查连接耗尽和系统资源

ss -ant state syn-recv '( sport = :22 )'
ss -ant '( sport = :22 )' | wc -l
df -h
df -i
free -h

磁盘或 inode 满、进程数限制、MaxStartups、MaxSessions 以及系统负载过高，都可能导致新连接失败。

七、代理与 MobaXterm 注意事项

如果终端工具配置了 SOCKS、HTTP Proxy、SSH Gateway 或跳板机，应先用直连测试排除代理。确认会话中没有残留旧 IP、错误端口、错误用户名或不匹配的私钥格式。客户端日志中的断开位置比“连接不上”更有诊断价值。

总结

SSH 排查应按“解析—网络—端口—服务—认证—用户环境”顺序进行。超时问题优先查网络，拒绝问题查监听，Permission denied 才查密钥。保留控制台应急通道，是避免远程配置失误演变成长期失联的关键。