大部分情况下，SSH 登录卡顿确实是因为服务端开启了 DNS 反向解析，将配置文件中的 UseDNS 设为 no 通常能直接解决这个问题，尤其是内网或缺乏可靠 DNS 服务器的环境。

操作前准备：备份与语法检查

修改 SSH 配置存在无法远程登录的风险，操作前务必备份配置文件并进行语法检查。

# 1. 备份配置文件
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# 2. 修改配置后，重启前必须检查语法
sudo sshd -t
# 若无输出则表示配置正确，若有报错请立即修正

命令速用版

# 1. 检查当前配置状态
grep -i "usedns" /etc/ssh/sshd_config

# 2. 修改配置（确保有一行明确的 UseDNS no）
sudo vim /etc/ssh/sshd_config

# 3. 语法检查（关键步骤）
sudo sshd -t

# 4. 重启服务
sudo systemctl restart sshd
# 或 CentOS 6: sudo service sshd restart

# 5. 客户端验证
ssh -v user@host

为什么会这样

SSH 登录慢通常不是网络带宽问题，而是服务端在认证前做了多余检查。默认情况下，OpenSSH 服务端会开启 UseDNS 选项，当客户端连接时，服务端会根据客户端 IP 进行 DNS 反向查询（查 PTR 记录），然后再正向查询 A 记录比对。如果客户端没有配置反向域名，或者 DNS 服务器响应慢、不可达，服务端就会等待查询超时，这个过程公开资料中常提及可能导致数秒至数十秒的延迟。

此外，GSSAPIAuthentication 默认开启也会尝试 Kerberos 认证协商，若环境未部署相关服务，同样会造成额外等待。这两个选项默认开启却极少被普通场景使用，关闭它们能显著减少登录前的握手时间。

分步处理

1. 确认并修改 UseDNS 配置

编辑/etc/ssh/sshd_config 文件。注意，即使文件中存在#UseDNS yes（被注释），OpenSSH 默认行为仍可能是开启的。必须显式写入一行未被注释的配置：

UseDNS no

同时建议关闭 GSSAPI 认证以减少非必要协商：

GSSAPIAuthentication no
GSSAPICleanupCredentials no

2. 检查系统名称解析配置

有些系统即使关了 UseDNS，仍可能因/etc/nsswitch.conf 配置不当导致其他系统调用走 DNS 而卡顿。检查 hosts 行：

hosts: files dns

确保 files 在前，dns 在后。若内网无可靠 DNS，可临时简化为 hosts: files。

3. 重启服务

修改配置后必须重启 sshd 服务才能生效。执行 sudo systemctl restart sshd 或对应系统的服务重启命令。

怎么验证是否生效

使用调试模式连接是最直接的验证方法。在客户端执行：

ssh -v user@host

观察输出日志。如果配置生效，日志中不应再出现 debug1: reverse mapping checking 或 Trying to reverse map address 这类提示。若仍有类似日志，说明配置未加载成功，可能是文件路径错误、语法错误或服务未真正重启。

也可以使用 time ssh user@host exit 命令测量真实连接耗时，对比优化前后的差异。

常见坑与风险排查

1. 配置未显式生效：仅仅注释掉 UseDNS yes 不够，必须明确写出 UseDNS no，因为默认值可能是 yes。

2. 服务未重启：改完配置不重启等于没改，且需确认重启命令执行成功，无报错。

3. 忽略 nsswitch.conf：某些场景下系统级主机名解析仍会拖慢登录后首次命令执行，需配合检查名称解析顺序。

4. 客户端参数无效：仅改客户端参数（如 ssh -o GSSAPIAuthentication=no）对服务端发起的反向 DNS 查询无效，必须改服务端配置。

5. 锁死风险与恢复：若配置错误导致 sshd 无法启动，切勿关闭当前连接。应通过控制台（VNC/物理机）登录恢复备份：cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config 并重启服务。

参考文档

更多配置细节可查阅官方手册：man sshd_config