别总盯着 SSH Key 看：一套层级排查法

很多人在公司部署环境或者连接远程服务器报错时，第一反应就是“是不是密钥过期了”或者“是不是权限没给对”，然后开始疯狂重生成 Key 或者重启服务。其实这种盲目尝试效率极低，最稳妥的办法是把报错信息当成“时间戳”——它告诉你连接在哪个环节断掉了。

我之前带新人做数据同步任务时，有个同事卡在 ssh demo-server 报错好久，死活在研究公钥，结果最后发现是 ssh: Could not resolve hostname。这说明 SSH 压根还没走到认证那一步，它连对方 IP 地址都没找到，换一百个 Key 也没用。

在公司推行 AI Agent 部署工作流时，我经常跟团队强调，SSH 连接其实有 7 个检查点，必须按顺序排查：

配置解析 → 域名解析 → TCP 连接 → 传输与密钥交换 → 服务器验证 → 用户认证 → 通道创建

如果域名解析没过，你研究用户认证就是浪费时间。

第一步：检查 SSH 配置解析

在发包之前，SSH 会先读 ~/.ssh/config。很多人习惯写别名，比如：

Host demo-server
 HostName 192.0.2.10
 User dev
 Port 22
 IdentityFile ~/.ssh/id_ed25519

这时候千万不要用肉眼去对配置，因为多个配置块可能会冲突。最稳妥的实操命令是：

ssh -G demo-server | grep -E '^(hostname|user|port|identityfile) '

这个命令能直接告诉你 SSH 最终解析出的 IP、用户和密钥路径是什么。如果这里就错了，那问题就在配置文件里，还没涉及到网络。

第二步：操作系统域名解析

如果配置没问题，SSH 会尝试把主机名转成 IP。这里有个大坑：很多同事把 Ansible 的 inventory 映射当成了系统级别的解析。Ansible 能认出 lab-gpu 是哪个 IP，但原生的 OpenSSH 并不读 Ansible 的文件。

如果你看到 Could not resolve hostname，说明配置阶段过了，但 OS 找不到地址。

Linux 环境排查：

getent hosts server.example.com

macOS 环境排查：

dscacheutil -q host -a name server.example.com

只有确认 IP 能通，再去考虑 TCP 握手和后续的密钥认证。把这个逻辑同步给团队后，我们排查环境问题的速度快了不少，毕竟不用再在不相关的地方打转。