useDNS配置導致登陸慢
如果ssh server的配置文件（通常是 /etc/ssh/sshd_config ）中設置 useDNS yes ，可能會導致 ssh 登陸卡住幾十秒。將該配置項設為 no，然后重啟 ssh 服務，再次登陸就恢復正常。將useDND配置為yes會導致登陸慢，原因是在登陸的過程中服務端會發送四次反向域名解析的請求，每次請求相隔5s，共20s，反映在登陸過程中就是卡了幾十秒。域名解析是根據域名查找所對應IP的過程，反過來， 反向域名解析就是根據IP查找域名的過程，ssh服務端向DNS服務器發起反向域名解析的請求，請求解析客戶端IP的域名。由於DNS服務器配置(該配置位於 /etc/resolv.conf )不正確，導致發出的請求沒有響應。
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服務端決定了支持哪些登陸方式。在登陸過程中經常協商之后有個認證的順序，然后依次選擇認證方式，直到認證成功（登錄方式可以通過ssh命令行中可以通過增加 -vvv 選項來打印整個登陸的過程的debug日志），我們不需要關心GSSAPI認證到底是什么鬼，只需關心為什么允許了GSSAPI認證就會導致ssh登陸慢呢？從debug信息很難看出來，還是通過抓包來看。通過抓包，同樣也發現有大量的DNS反向域名解析的報文，但這次需要解析的是服務端的IP，同樣由於客戶端側配置的DNS服務器不可達，導致超時重試多次。結合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、主機名對應關系
參考：http://ju.outofmemory.cn/entry/344691