Linux ssh登陸慢的兩種原因分析

如果做運維就一定會遇到ssh登陸Linux伺服器慢的問題，問題比較好解決，一般Google之後有很多文章都告訴你解決方法，但是很少有文章分析為什麼會慢，這篇文章簡單分析下ssh登陸慢的原因。

useDNS配置導致登陸慢

如果ssh server的配置文件（通常是 /etc/ssh/sshd_config ）中設置 useDNS yes ，可能會導致 ssh 登陸卡住幾十秒。按照網上的方法將該配置項設為 no，然後重啟 ssh 服務，再次登陸就恢復正常，但至於為什麼改配置項會導致登陸慢，下麵的例子是從虛擬機192.168.0.64 ssh登陸192.168.0.188，在 188 用 tcpdump 進行抓包，如下圖：

從圖中可以看出在登陸的過程中服務端188發了四次反向功能變數名稱解析的請求，每次請求相隔5s，共20s，反映在登陸過程中就是卡了幾十秒。功能變數名稱解析是根據功能變數名稱查找所對應IP的過程，反過來， 反向功能變數名稱解析就是根據IP查找功能變數名稱的過程，從抓包的圖中看出ssh服務端(192.168.0.188)向DNS伺服器(10.0.0.10/10.0.0.11)發起反向功能變數名稱解析的請求，請求解析客戶端IP(192.168.0.64)的功能變數名稱。由於DNS伺服器配置(該配置位於 /etc/resolv.conf )的不正確，導致發出的請求未有響應，每隔5s超時重試一次。

ssh中該配置主要用於安全加固，伺服器會先根據客戶端的IP地址進行DNS PTR反向查詢出客戶端的主機名，然後根據查詢出的客戶端主機名進行DNS正向A記錄查詢，並驗證是否與原始IP地址一致，通過此種措施來防止客戶端欺騙。但平時我們登陸伺服器的客戶端IP基本在DNS伺服器中沒有PTR記錄，因此該功能顯得很無用，推薦直接設為no，當然如果你理解了上述的過程，也能找到其他方法保證即使該配置打開了也不慢：

• 在配置文件 /etc/ssh/sshd_config 中設置一個可達的DNS伺服器
• 在 /etc/hosts 文件中手動添加一條你登陸客戶端與主機名的對應關係

GSSAPIAuthentication配置導致登陸慢

除了常見的useDNS配置可能導致ssh登陸慢之外，還有一個配置GSSAPIAuthentication也會導致登陸慢，該配置項的含義是允許GSSAPI認證，屬於ssh協議的一種認證方式。ssh協議有多種認證方式，平時常用的有密碼認證、公鑰認證等，但ssh協議支持的遠不止這兩種，那麼至於一次ssh登陸到底用哪種認證方式是怎麼決定的呢？這個取決於ssh的客戶端和服務端的協商的結果，ssh服務端決定了支持哪些登陸方式，這裡以OpenSSH的服務端配置（ /etc/ssh/sshd_config ）為例：

ssh客戶端決定了使用哪種登陸方式，這裡以OpenSSH的客戶端配置（ /etc/ssh/ssh_config ）為例：

在登陸過程中經常協商之後有個認證的順序，然後依次選擇認證方式，直到認證成功，ssh命令行中可以通過增加 -vvv 選項來進行debug整個登陸的過程，如下為節選的登陸過程日誌，可以看出會逐個嘗試不同方式去認證：

我們不需要關心GSSAPI認證到底是什麼鬼，只需關心為什麼允許了GSSAPI認證就會導致ssh登陸慢呢？直接看debug信息很難看出來，還是通過抓包來看。下麵例子是通過虛擬機192.168.0.214 ssh登陸192.168.0.188，這次我們在ssh的客戶端進行抓包：

同樣也發現有大量的DNS反向功能變數名稱解析的報文，但這次需要解析的是服務端的IP（192.168.0.188），同樣由於客戶端側配置的DNS伺服器（10.8.8.8）不可達，導致超時重試多次。結合ssh登陸的過程日誌，不難發現這寫DNS反向功能變數名稱解析的報文是GSSAPI認證需要的。

那麼解決該問題就比較簡單了，下麵任何一種都可：

• ssh 客戶端配置（ /etc/ssh/ssh_config ）將 GSSAPIAuthentication 設為 no
• ssh 服務端配置（ /etc/ssh/sshd_config ）將 GSSAPIAuthentication 設為 no
• ssh 客戶端正確配置 DNS 伺服器（ /etc/resolv.conf ）
• ssh 客戶端 hosts 文件（ /etc/hosts ）增加服務端的IP、主機名對應關係

總結

本文分析了ssh的兩個配置可能導致登陸慢的原因以及解決方法，主要想說的是通過抓包可以很容易分析登陸慢的原因。