SSH 连接失败时，如何按网络、服务与认证逐层定位

🔎 SSH 连接失败：网络、服务和认证的分层排查

SSH 故障常被统称为“连不上”，但客户端的超时、连接拒绝和认证失败对应不同阶段。排查时固定同一个来源地址、目标和端口，保存完整错误与时间，再从网络通路开始逐层推进。每次只改变一个变量，才能知道哪项证据支持结论。

🔎 一、先定位 TCP 是否到达主机

用 ssh -vvv -p 端口 用户@主机 查看客户端协商过程。若停在建立连接前，使用 nc -vz 主机 端口 对目标 TCP 端口做连通性测试。持续超时通常意味着包未获得回应，应核对目标地址是否正确、来源网络是否能出站、云侧入站规则是否放行该来源和端口，以及实例主机防火墙是否允许流量。

ICMP ping 不通不能推出 SSH 一定不通，因为网络策略可能单独过滤 ICMP。反过来，ping 成功也不能证明 SSH 端口可达。应以 TCP 握手结果和实际 SSH 阶段作为判断依据，并在需要时对照网络设备或主机侧日志中的时间戳。

🧭 二、区分未监听、绑定错误和服务故障

如果 TCP 测试立即返回拒绝，目标通常可达但该端口没有接受连接的监听者，或路径设备主动拒绝。通过云控制台或已有管理会话查看服务状态，例如 systemctl status sshd；某些系统单元名称是 ssh。再用 ss -lntp 查看实际监听端口和绑定地址。

服务只绑定 127.0.0.1 时，本机访问可能成功而外部访问失败；配置端口与客户端目标不一致也会出现类似现象。修改配置前检查是否由多个配置文件覆盖。用 sshd -t 做语法校验后再按系统服务管理流程加载配置，并保留一个可用会话，避免误改后失去恢复入口。

📊 三、服务已回应后检查认证链

客户端已经收到 SSH 服务回应，但最终登录失败，重点转向用户名、密钥与授权策略。用 ssh -i 密钥文件 -vvv 用户@主机 明确指定客户端密钥，观察服务器是否接受对应公钥。检查服务端认证日志中的拒绝原因，并核对用户是否被允许、目标账号家目录是否正确、.ssh 和 authorized_keys 是否由该用户拥有且未向其他用户开放写权限。

✅ 四、容易误判的情况与验收

客户端同时加载多把密钥，可能触发服务器认证尝试上限；用户名错误也可能让正确密钥无法通过。网络设备丢弃流量和主机服务未运行都可能表现为超时，因此错误文本只是分流证据，不是最终根因。

修复后的验收应从同一客户端来源建立新会话，确认目标用户和权限正确，并用一项预期受限的来源或认证路径验证限制仍生效。记录错误阶段、目标端口、监听地址、日志时间与最终结果，后续重复故障便可快速比较。