共计 1283 个字符，预计需要花费 4 分钟才能阅读完成。
本文由 LinuxProbe.Com 团队成员 岳国帅 整理发布，原文来自：Linux 就该这么学。
| 导读 | 通过 SSH 登录 Linux 服务器时，输完用户名就卡住了，要等待 10 秒钟才提示密码输入。这究竟是什么原因导致的呢？ |
10 秒钟的时间并不算长，吃个薯片喝口咖啡就过去了。但是作为强迫症患者，我还是容不得它的存在，因此便决定写篇文章，向大家演示一下怎样用 Wireshark 一步步解决这个问题。
- 在 Linux 服务器上启动抓包。
- 从笔记本 SSH 到 Linux 服务器，输入用户名并回车。
- 等待 10 秒左右，直到登录界面提示输入密码。
- 停止抓包。
这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量，不用过滤也可以分析，不过我们最好在做实验时就养成过滤的习惯，以适应生产环境中抓到的包。因为我们是通过 SSH 协议登录的，所以可以直接用“ssh”来过滤，如图所示。SSH 包都是加密了的，因此我们看不出每个包代表了什么意思，不过这并不影响分析。从图 2 中可以看到，21 号包和 25 号包之间恰好就相隔 10 秒。
这两个包之间所发生的事件，可能就是导致这个现象的原因。于是我再用“frame.number> 21 && frame.number< 25”过滤，结果如图所示。
从图中可以看到，Linux 服务器当时正忙着向 DNS 服务器查询 10.32.200.23 的 PTR 记录（即反向解析），试图获得这个 IP 地址所对应的域名。该 IP 属于我们测试所用的笔记本，但由于 DNS 服务器上没有它的 PTR 记录，所以两次查询都等了 5 秒钟还没结果，总共浪费了 10 秒钟。
我们由此可以推出，这台 Linux 服务器在收到 SSH 访问请求时，会先查询该客户端 IP 所对应的 PTR 记录。假如经过 5 秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了 5 秒还没回复，就彻底放弃查询。我们甚至可以进一步猜测，如果 DNS 查询能成功，就不用白等那 10 秒钟了。
为了验证这个猜测，我在 DNS 服务器中添加了 10.32.200.23 的 PTR 记录，如图所示，然后再次登录。
这一次果然立即登录进去了。从图的 Wireshark 截屏可见，DNS 查询是成功的，所以 21 号包和 26 号包之间几乎是没有时间停顿的。
明白了 DNS 查询就是问题的起因，接下来就知道怎么进一步研究了。只要在 Google 搜索“ssh dns”，第一页出来的链接都是关于这个问题的。随便挑几篇阅读一下，就连我这样的 Linux 初学者都能把这个问题研究透了。原来这个行为是定义在“/etc/ssh/sshd_config”文件中的，默认配置是这样的：
[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usedns
#UseDNS yes改成下面这样就可以解决了，不用去动 DNS 服务器上的配置：
[root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns
UseDNS no
