首頁 > 軟體

診斷並解決 SSH 連線慢的方法

2020-06-16 17:57:26

每次PuTTY使用SSH登入到遠端的Linux進行管理的時候，遠端登入的過程都非常慢——輸入完使用者名稱之後，非要等到30秒左右才會出來輸入密碼的提示。在實際處理問題的時候，特別需要快速響應的時候，這種狀況著實讓人難以忍受。

但後來具體測試了一下，發現這又並非是每種系統的通病，出現問題的機器主要集中的CentOS上，同樣的Debian系統，在遠端連線的過程就是健步如飛，絲毫沒有卡頓猶豫的感覺。這難道是CentOS的問題？

 

出於好奇，檢視了下兩個系統在SSH時的差別

CentOS：

  1. ssh -v ssh_test@192.168.128.137

SSH遠端登入的時候顯示的資訊如下：

  1. OpenSSH_6.0p1Debian-4,OpenSSL1.0.1e11Feb2013
  2. ...Some sensitive information...
  3. debug1:Remote protocol version 2.0, remote software version OpenSSH_5.3
  4. debug1: match:OpenSSH_5.3 pat OpenSSH_5*
  5. debug1:Enabling compatibility mode for protocol 2.0
  6. debug1:Local version string SSH-2.0-OpenSSH_6.0p1Debian-4
  7. debug1: SSH2_MSG_KEXINIT sent
  8. debug1: SSH2_MSG_KEXINIT received
  9. debug1: kex: server->client aes128-ctr hmac-md5 none
  10. debug1: kex: client->server aes128-ctr hmac-md5 none
  11. debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
  12. debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
  13. debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
  14. debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
  15. ...Some sensitive information...
  16. debug1: ssh_rsa_verify: signature correct
  17. debug1: SSH2_MSG_NEWKEYS sent
  18. debug1: expecting SSH2_MSG_NEWKEYS
  19. debug1: SSH2_MSG_NEWKEYS received
  20. debug1:Roamingnot allowed by server
  21. debug1: SSH2_MSG_SERVICE_REQUEST sent
  22. debug1: SSH2_MSG_SERVICE_ACCEPT received
  23. debug1:Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  24. debug1:Next authentication method: gssapi-keyex
  25. debug1:No valid Key exchange context
  26. debug1:Next authentication method: gssapi-with-mic
  27. debug1:Unspecified GSS failure.Minor code may provide more information
  28. Cannot determine realm for numeric host address
  29. debug1:Unspecified GSS failure.Minor code may provide more information
  30. Cannot determine realm for numeric host address
  31. debug1:Unspecified GSS failure.Minor code may provide more information
  32. debug1:Unspecified GSS failure.Minor code may provide more information
  33. Cannot determine realm for numeric host address
  34. debug1:Next authentication method: publickey
  35. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_rsa
  36. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_dsa
  37. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_ecdsa
  38. debug1:Next authentication method: password

而Debian使用同樣的命令測試的結果為：

  1. OpenSSH_6.0p1Debian-4,OpenSSL1.0.1e11Feb2013
  2. ...Some sensitive information...
  3. debug1:Remote protocol version 2.0, remote software version OpenSSH_6.0p1Debian-4
  4. debug1: match:OpenSSH_6.0p1Debian-4 pat OpenSSH*
  5. debug1:Enabling compatibility mode for protocol 2.0
  6. debug1:Local version string SSH-2.0-OpenSSH_6.0p1Debian-4
  7. debug1: SSH2_MSG_KEXINIT sent
  8. debug1: SSH2_MSG_KEXINIT received
  9. debug1: kex: server->client aes128-ctr hmac-md5 none
  10. debug1: kex: client->server aes128-ctr hmac-md5 none
  11. debug1: sending SSH2_MSG_KEX_ECDH_INIT
  12. debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  13. ...Some sensitive information...
  14. debug1: ssh_ecdsa_verify: signature correct
  15. debug1: SSH2_MSG_NEWKEYS sent
  16. debug1: expecting SSH2_MSG_NEWKEYS
  17. debug1: SSH2_MSG_NEWKEYS received
  18. debug1:Roamingnot allowed by server
  19. debug1: SSH2_MSG_SERVICE_REQUEST sent
  20. debug1: SSH2_MSG_SERVICE_ACCEPT received
  21. debug1:Authentications that can continue: publickey,password
  22. debug1:Next authentication method: publickey
  23. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_rsa
  24. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_dsa
  25. debug1:Tryingprivate key:/home/mitchellchu/.ssh/id_ecdsa
  26. debug1:Next authentication method: password

從上面可以看到，在CentOS中，系統使用了publickey，gssapi-keyex，gssapi-with-mic，和password來進行認證（上面顏色標記行，23行），而Debian此時則使用了Publickey和password兩種。在連線CentOS的時候，在23行處花費了相當多的時間。我們在那裡開始往下看，就能非常清楚的看到下面的資訊：

  1. #下面使用的是GSSAPI-KEYEX來進行驗證
  2. debug1:Next authentication method: gssapi-keyex
  3. #但是報錯：沒有可用的Key來交換資訊
  4. debug1:No valid Key exchange context
  5. #系統接著又使用下一個驗證方法：GSSAPI-WITH-MIC
  6. debug1:Next authentication method: gssapi-with-mic
  7. #但遺憾的是，GSSAPI-WITH-MIC方法也失敗。
  8. #原因：不能確定數位主機地址的域
  9. debug1:Unspecified GSS failure.Minor code may provide more information
  10. Cannot determine realm for numeric host address
  11. debug1:Unspecified GSS failure.Minor code may provide more information
  12. Cannot determine realm for numeric host address
  13. debug1:Unspecified GSS failure.Minor code may provide more information
  14. debug1:Unspecified GSS failure.Minor code may provide more information
  15. Cannot determine realm for numeric host address
  16. # 在嘗試幾次後，SSH認證終於放棄了這種驗證。進入下一個驗證：Publickey
  17. debug1:Next authentication method: publickey

除了這個方法還有其他方法麼？這個自然是有的，CentOS其實就已經提供給我們一個解決方案了——使用ssh遠端登入的時候禁用GSSAPI驗證。當然，還有一個問題不得不注意，如果你的機器上啟用了UseDNS的話，需要一併關閉，具體可參見最後的說明。

從錯誤可以看出應該是和主機域相關的問題——應該是無法確認IP對應的域，因此會出現這個問題。GSSAPI主要是基於Kerberos的，因此要解決這個問題也就變得要系統設定有Kerberos，這對於沒有Kerberos的筒子們來說，設定個Kerberos就為了解決個登入延時問題，似乎不是個明智的決定——特別是在生產環境中！最小化滿足需求才是王道。

 

下面先放出處理GSSAPI的方法

禁用GSSAPI認證有兩個方式：用戶端和伺服器端

 

1. 用戶端禁用

比較簡單，影響的只有單個用戶端使用者，可以用下面的方法實現：

  1. ssh -o GSSAPIAuthentication=no your-server-username@serverIP

用上面的方法登入遠端，即可實現禁用GSSAPIAuthentication。

如果你嫌麻煩，直接設定你ssh用戶端的檔案/etc/ssh/ssh_config來達到永久解決這個問題：

  1. vi /etc/ssh/ssh_config
  2. ### 找到ssh_config檔案裡面的GSSAPIAuthentication yes這行
  3. ### 修改為GSSAPIAuthentication no
  4. ### 儲存ssh_config檔案並退出

這個修改方法是將所有這個機器上的使用者都影響到了，如果你影響面不要那麼的廣泛，只要在指定的使用者上實施禁用GSSAPIAuthentication的話，那麼你可以在該使用者的目錄下，找到.ssh目錄，在其下面新增config檔案，並在檔案內新增上面這句，如果沒有這個檔案，你也可以直接這麼做：

  1. cat >>~/.ssh/config<<EOF
  2. GSSAPIAuthenticationno
  3. EOF

使用cat，直接將輸入匯出到檔案中，這時候，你在使用ssh連線遠端的目標主機時，就不會再使用GSSAPI認證了。

上面這些檔案是在用戶端，不是伺服器端的。也就是說，要修改這個檔案，你的用戶端也要是Linux才行。

如果你是在Windows下使用PuTTY這樣的用戶端工具，就不使用上面這個方法了，PuTTY下可以嘗試在連線之前進行設定：

PuTTY Configuration -> Connection -> SSH -> Auth -> GSSAPI -> (取消勾選)Attempt GSSAPI authentication(SSH-2 only)

如果沒有關閉PuTTY的GSSAPIAuthentication，你可以在連線的視窗右鍵（或：Ctrl + 右鍵）檢視紀錄檔，可以發現PuTTY會自動嘗試GSSAPI連線的紀錄檔：

  1. 2014-05-1823:46:54Using SSPI from SECUR32.DLL
  2. 2014-05-1823:46:54Attempting GSSAPI authentication
  3. 2014-05-1823:46:54 GSSAPI authentication request refused

恩，上面基本上將用戶端禁止GSSAPIAuthentication的方法羅列了一下。

注意：上面這些方法是比較通用的。

 

2、如果你已經設定了Kerberos的情況下

那麼你也可以嘗試下如下的用戶端解決這個問題的方法：

新增遠端主機的主機名到你本機的host檔案中（Linux是/etc/hosts，Windows是系統磁碟:WindowsSystem32driversetchosts）。Linux和Windows下都可以新增下面這行。

  1. ### 注意：下面這樣的IP-Addr要替換成你的遠端機器的IP地址，HostName，自然是主機名
    IP-AddrHostName

新增完畢之後，儲存退出。

如果你沒有設定Kerberos的話，僅設定這個hosts檔案一樣是不能解決問題的，在使用ssh登入的時候，你可以看到報錯紀錄檔會類似下面這樣：

  1. debug1:Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
  2. debug1:Next authentication method: gssapi-keyex
  3. debug1:No valid Key exchange context
  4. debug1:Next authentication method: gssapi-with-mic
  5. debug1:Unspecified GSS failure.Minor code may provide more information
  6. Credentials cache file '/tmp/krb5cc_0'not found
  7. debug1:Unspecified GSS failure.Minor code may provide more information
  8. Credentials cache file '/tmp/krb5cc_0'not found
  9. debug1:Unspecified GSS failure.Minor code may provide more information
  10. debug1:Unspecified GSS failure.Minor code may provide more information
  11. Credentials cache file '/tmp/krb5cc_0'not found
  12. debug1:Next authentication method: publickey

這個錯誤我在剛開始的時候也犯了的，需要注意。

 

3、伺服器端禁用GSSAPIAuthentication。

直接到/etc/ssh/sshd_config裡面，將GSSAPIAuthentication yes改為no即可了，同時也請注意，你可能也需要將UseDNS這個也修改成UseDNS no（這個要注意，每個系統的預設值不同，此處以CentOS 6為例）：

  1. sudo vi /etc/ssh/sshd_config
  2. ### 普通使用者許可權不夠，需要root許可權
  3. ### 找到GSSAPIAuthentication yes，修改為
  4. ### GSSAPIAuthentication no
  5. ### 注意，這裡你也需要將UseDNS修改為no，CentOS預設是yes，即使這行已被註釋，你也需要加上
  6. ### UseDNS no
  7. ### 有看到人說UseDNS yes不需要修改為UseDNS no，Mitchell測試下來是需要的。
  8. ### 儲存檔案，退出

當禁用之後，我們需要重新啟動SSH服務來保證新的組態檔被正確應用：

  1. service sshd restart

這個時候，再次使用SSH登入這個主機時，是不是感覺飛快了？

呼～ 終於完成了這篇長文，要一邊搗騰一邊弄出這些個文字，還是真是有點困難。不過，這樣也就將問題搗騰的差不多了，希望看文章的你能夠看的明白，歡迎討論。 

 

說明：

1. GSSAPI：Generic Security Services Application Program Interface，GSSAPI本身是一套API，由IETF標準化。其最主要也是著名的實現是基於Kerberos的。一般說到GSSAPI都暗指Kerberos實現。

2. UseDNS：是OpenSSH伺服器上的一個DNS查詢選項，而且預設還是開啟的，在開啟的狀態下，每當用戶端嘗試連線OpenSSH伺服器的時候，伺服器端就自動根據使用者用戶端的IP進行DNS PTR反向查詢（IP反向解析才會有記錄），查詢出IP對應的Hostname，之後在根據用戶端的Hostname進行DNS正向A記錄查詢。通過這個查詢，驗證IP是否和連線的用戶端IP一致。但絕大部分我們的機器是動態獲取IP的，也就是說，這個選項對於這種情況根本就沒用——即使是普通靜態IP伺服器，只要沒有做IP反向解析，也難以適用。如果你符合這些情況，建議關閉UseDNS以提高SSH遠端登入時候的認證速度。

SSH服務遠端存取Linux伺服器登陸慢 http://www.linuxidc.com/Linux/2011-08/39742.htm

提高Ubuntu的SSH登陸認證速度的辦法 http://www.linuxidc.com/Linux/2014-09/106810.htm

開啟SSH服務讓Android手機遠端存取 Ubuntu 14.04  http://www.linuxidc.com/Linux/2014-09/106809.htm

如何為Linux系統中的SSH新增雙重認證 http://www.linuxidc.com/Linux/2014-08/105998.htm

在 Linux 中為非 SSH 使用者設定 SFTP 環境 http://www.linuxidc.com/Linux/2014-08/105865.htm

Linux 上SSH 服務的設定和管理 http://www.linuxidc.com/Linux/2014-06/103627.htm

SSH入門學習基礎教學 http://www.linuxidc.com/Linux/2014-06/103008.htm

SSH免密碼登入詳解  http://www.linuxidc.com/Linux/2015-03/114709.htm

本文永久更新連結地址：http://www.linuxidc.com/Linux/2015-07/120171.htm


相關文章
IT145.com E-mail:sddin#qq.com