SSH 登录慢得像在拨号？先查这三个耗时大户

服务器明明负载不高、网络延迟也正常，ssh 登录却要卡十几秒才进 shell。密码都输完了，光标在那转圈——这种慢，大概率不是网络问题，而是登录流程里某个环节在"等超时"。用 ssh -vvv 看一眼时间戳断点，基本能定位到下面三个嫌疑人之一。

1. 反向 DNS 解析：UseDNS yes 是最常见的坑

OpenSSH 服务端默认 UseDNS yes，每次有连接进来，它会拿客户端 IP 做一次反向 DNS 查询，用来写日志和做 AllowUsers/DenyUsers 的主机名匹配。

公网环境下，反查经常超时（反向解析记录本来就少），而 sshd 会等查询超时才继续，一个连接就白白卡 10～20 秒。

排查：服务端 journalctl -u sshd 看连接日志时间间隔；客户端 ssh -vvv 会在 “Authentications that can continue” 之前明显停顿。

解法：/etc/ssh/sshd_config 里加 UseDNS no，然后 systemctl reload sshd。注意两点：一是只做内网、且审计日志依赖主机名解析的场景要评估；二是改完用新开一个会话验证，别把当前会话先断掉。

2. GSSAPI 认证：没 Kerberos 也在傻等

很多发行版默认 GSSAPIAuthentication yes。客户端发起 GSSAPI 认证时，会去尝试找 KDC（Kerberos 密钥分发中心），内网根本没有这东西，于是又是一轮超时等待。

症状很典型：ssh -vvv 输出里在 gssapi-with-mic 这一行停顿很久，最后 fallback 到 publickey/password 才成功。

解法（二选一）：客户端 ~/.ssh/config 里对这台主机加 GSSAPIAuthentication no；或者服务端 sshd_config 直接关掉。客户端侧改最稳妥，不影响其他人。

3. PAM / 会话建立慢：登录成功后还卡

如果认证很快通过、但进 shell 前又卡住，问题多半在 PAM 栈或 systemd-logind 会话建立上。常见诱因：pam_systemd 等 logind 响应慢、motd 动态脚本执行慢（有的发行版登录时会跑一堆统计脚本）。

排查：systemd-analyze blame 看看有没有拖后腿的服务；临时把 /etc/pam.d/sshd 里的 session optional pam_motd.so 注释掉对比一下。

一套固定的排查顺序

1. ssh -vvv user@host，看时间戳断点卡在哪一行；
2. 卡在认证前 → 查 UseDNS / 防火墙反向解析；
3. 卡在 gssapi-with-mic → 关 GSSAPI；
4. 认证通过后卡 → 查 PAM、motd、systemd-logind；
5. 服务端同步看 journalctl -u sshd --since "5 min ago" 对照时间线。

改配置的铁律：永远保留一个已登录的会话做"逃生通道"，改完 reload 而不是 restart，确认新会话正常后再退出旧会话。sshd 配错把自己锁在门外，是运维生涯里最不值得的一课。