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 

 

免費提供最新Linux技術教程書籍，爲開源技術愛好者努力作得更多更好：http://www.linuxprobe.com/