文：林沛满
到今天为止，已经有5位读者向我求助过这个问题了。症状请看图1，他们通过SSH登录Linux服务器时，输完用户名就卡住了，要等待10秒钟才提示密码输入。这究竟是什么原因导致的呢？其实我也是Linux菜鸟，虽然尝试过搜索“ssh hang”等关键词，但是没找到相关信息。
图1
10秒钟的时间并不算长，吃个薯片喝口咖啡就过去了。但是作为强迫症患者，我还是容不得它的存在，因此便决定写篇文章，向大家演示一下怎样用Wireshark一步步解决这个问题。
首先是抓包，步骤如下。
1．在Linux服务器上启动抓包。
2．从笔记本SSH到Linux服务器，输入用户名并回车。
3．等待10秒左右，直到登录界面提示输入密码。
4．停止抓包。
这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量，不用过滤也可以分析，不过我们最好在做实验时就养成过滤的习惯，以适应生产环境中抓到的包。因为我们是通过SSH协议登录的，所以可以直接用“ssh”来过滤，如图2所示。SSH包都是加密了的，因此我们看不出每个包代表了什么意思，不过这并不影响分析。从图2中可以看到，21号包和25号包之间恰好就相隔10秒。
图2
这两个包之间所发生的事件，可能就是导致这个现象的原因。于是我再用“frame.number> 21 && frame.number< 25”过滤，结果如图3所示。
图3
从图3中可以看到，Linux服务器当时正忙着向DNS服务器查询10.32.200.23的PTR记录（即反向解析），试图获得这个IP地址所对应的域名。该IP属于我们测试所用的笔记本，但由于DNS服务器上没有它的PTR记录，所以两次查询都等了5秒钟还没结果，总共浪费了10秒钟。
我们由此可以推出，<strong>这台Linux服务器在收到SSH访问请求时，会先查询该客户端IP所对应的PTR记录。假如经过5秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了5秒还没回复，就彻底放弃查询。</strong>我们甚至可以进一步猜测，如果DNS查询能成功，就不用白等那10秒钟了。
为了验证这个猜测，我在DNS服务器中添加了10.32.200.23的PTR记录，如图4所示，然后再次登录。
图4
这一次果然立即登录进去了。从图5的Wireshark截屏可见，DNS查询是成功的，所以21号包和26号包之间几乎是没有时间停顿的。
图5
明白了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
我经常说<strong>技能比知识更重要</strong>，这就是例子之一。学会了使用Wireshark，其他知识也会跟着来的。
本文摘自《Wireshark网络分析的艺术》，作者林沛满。
《Wireshark网络分析的艺术》挑选的网络包来自真实场景，经典且接地气。讲解时采用了生活化的语言，力求通俗易懂，以使读者在轻松阅读的过程中，既可以学到实用的网络知识，又能形成解决问题的思路。
与大多网络图书的课堂式体验不同，阅读《Wireshark网络分析的艺术》的感觉更像在听技术圈的朋友分享经验，除了知识，还有心情和想法。本书的覆盖范围从日常使用的手机App，到企业级的数据中心；从对付运营商的网络劫持，到开发自己的分析工具，不一而足。无论你是系统管理员、实施工程师、技术支持、网管、培训教师，还是开发和测试人员，都适合阅读本书。
网友评论