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

2022-09-03 05:42:09 字數 1743 閱讀 6434

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

如果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,當然如果你理解了上述的過程,也能找到其他方法保證即使該配置開啟了也不慢:

除了常見的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的兩個配置可能導致登陸慢的原因以及解決方法,主要想說的是通過抓包可以很容易分析登陸慢的原因。

外網登陸SAP的兩種方式

1 用sap router實現從外網登入sapserver 方式一 sapserverip 192.168.0.2,路由器中設為dmz區 在sapserver上啟用sap router,就可以 sap router的搭建很easy 1.找到sap的安裝資料夾 比如d usr sap ecc dveb...

shiro處理兩種路徑進行登陸問題

1.以下是我的shiro配置 static anon userfiles anon login authc logout logout user 當我需要使用兩個位址都進行登陸時 新增了一句 welogin authc 但是當我提交的位址是 welogin時卻沒有走登陸流程。但是提交位址是 logi...

SSH兩種登陸方式解釋

1 基於使用者名稱和密碼登陸 看圖就好啦 2 免密登陸 免密登陸解釋 1 首先在客戶端生成一對金鑰 ssh keygen 2 並將客戶端的公鑰 ssh copy id 拷貝到服務端 3 當客戶端再次傳送乙個連線請求,包括 ip 使用者名稱 4 服務端得到客戶端的請求後,會到 authorized k...