| 導讀 | 通過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
本文轉載自：http://www.linuxprobe.com/linux-connect-slowly.html
更多Linux干貨請訪問：http://www.linuxprobe.com/