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服務端認證配置

ssh客戶端決定了使用哪種登陸方式,這裏以OpenSSH的客戶端配置( /etc/ssh/ssh_config )爲例:

ssh客戶端認證配置

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

ssh認證日誌

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

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的兩個配置可能導致登陸慢的原因以及解決方法,主要想說的是通過抓包可以很容易分析登陸慢的原因。
如下取消dns反向解析已解決上述問題:

[root@k8s-master-1 ~]# ansible ceph-nodes -m shell -a ‘sed -i “s/#UseDNS yes/UseDNS no/g” /etc/ssh/sshd_config’
[WARNING]: Consider using the replace, lineinfile or template module rather than running sed. If you need to use command because replace, lineinfile or
template is insufficient you can add warn=False to this command task or set command_warnings=False in ansible.cfg to get rid of this message.
109.105.1.246 | SUCCESS | rc=0 >>

109.105.1.176 | SUCCESS | rc=0 >>

109.105.1.232 | SUCCESS | rc=0 >>

109.105.1.180 | SUCCESS | rc=0 >>

109.105.1.254 | SUCCESS | rc=0 >>

[root@k8s-master-1 ~]# ansible ceph-nodes -m command -a ‘systemctl restart sshd’
109.105.1.246 | SUCCESS | rc=0 >>

109.105.1.176 | SUCCESS | rc=0 >>

109.105.1.180 | SUCCESS | rc=0 >>

109.105.1.232 | SUCCESS | rc=0 >>

109.105.1.254 | SUCCESS | rc=0 >>

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章