ssh连接卡顿在“输入用户名后”几秒不动，95%是服务端认证前执行反向dns查询（usedns yes）和gssapi协商（gssapiauthentication yes）导致超时；禁用这两项并重启sshd即可秒解。
SSH连接卡在“输入用户名后、还没弹出密码框”那几秒，95%不是网络问题，而是服务端在认证前做了两件多余的事：反向DNS查询和GSSAPI协商。关掉 UseDNS 和 GSSAPIAuthentication 就能秒解。
怎么确认卡点就在认证前？
用 ssh -v user@host 观察日志停顿位置：
- 如果停在
debug1: Connecting to ...之后、debug1: Authenticating to ...之前 → 查客户端 DNS 或路由（比如 IPv6 fallback 卡住） - 如果停在
debug1: Authenticating to ...和debug1: Server accepts key ...之间 → 典型的UseDNS或GSSAPIAuthentication超时 - 如果已显示
Authenticated to ...还卡着 → 问题在 PAM、shell 初始化或 home 目录挂载，和 SSH 配置无关
/etc/ssh/sshd_config 必改两项
这两项默认是 yes，但绝大多数环境根本用不到：
-
UseDNS no：禁用服务端对客户端 IP 做 PTR 查询，避免因无 DNS 记录或 DNS 响应慢而等满 5–10 秒 -
GSSAPIAuthentication no：跳过 Kerberos 凭据加载尝试，否则会额外耗时 2–4 秒且几乎总失败
改完必须执行 sudo systemctl restart sshd 生效。临时验证可用：ssh -o UseDNS=no -o GSSAPIAuthentication=no user@host。
别漏掉 /etc/nsswitch.conf 这个隐藏开关
有些机器即使关了 UseDNS 还是慢，因为 getent hosts 或 getent ahosts 调用底层解析时被卡住。检查 /etc/nsswitch.conf 中这行：
hosts: files dns
如果 DNS 不可靠（比如内网没配 PTR、或 resolv.conf 里有失效 nameserver），就改成：
hosts: files
或者更稳妥的：hosts: files [UNAVAIL=return] dns，让 DNS 不可用时立刻回退，不等超时。
客户端连不上或反复超时，可能根本不是服务端的问题
现象是 “Connection timed out”，但实际是客户端优先走 IPv6，而本地网络或中间设备不支持 IPv6 路由，导致卡几十秒才降级到 IPv4：
- 临时解决：
ssh -4 user@host - 永久解决：在
~/.ssh/config加Host *段，写入AddressFamily inet - 顺手检查
/etc/resolv.conf是否含无效nameserver，以及/etc/nsswitch.conf的hosts行是否混入了mdns4_minimal这类 mDNS 插件（尤其 macOS 共享主机或某些桌面版 Linux）
真正难排查的是那种“登录快、敲命令却卡顿”的情况——那是 TCP 空闲断连在作祟，得靠 ClientAliveInterval 和 ClientAliveCountMax 配合保活，而不是改 DNS 设置。
