1. <wbr id="cnjas"><legend id="cnjas"></legend></wbr>

          Linux培訓
          達內IT學院

          400-111-8989

          診斷并解決 SSH 連接慢的方法

          • 發布:佚名
          • 來源:網絡
          • 時間:2015-07-20 16:01

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

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

          出于好奇,查看了下兩個系統在SSH時的差別

          CentOS:

          ssh -v ssh_test@192.168.128.137

          SSH遠程登錄的時候顯示的信息如下:

          OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
          ...Some sensitive information...
          debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
          debug1: match: OpenSSH_5.3 pat OpenSSH_5*
          debug1: Enabling compatibility mode for protocol 2.0
          debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
          debug1: SSH2_MSG_KEXINIT sent
          debug1: SSH2_MSG_KEXINIT received
          debug1: kex: server->client aes128-ctr hmac-md5 none
          debug1: kex: client->server aes128-ctr hmac-md5 none
          debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
          debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
          debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
          debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
          ...Some sensitive information...
          debug1: ssh_rsa_verify: signature correct
          debug1: SSH2_MSG_NEWKEYS sent
          debug1: expecting SSH2_MSG_NEWKEYS
          debug1: SSH2_MSG_NEWKEYS received
          debug1: Roaming not allowed by server
          debug1: SSH2_MSG_SERVICE_REQUEST sent
          debug1: SSH2_MSG_SERVICE_ACCEPT received
          debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
          debug1: Next authentication method: gssapi-keyex
          debug1: No valid Key exchange context
          debug1: Next authentication method: gssapi-with-mic
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
           
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
           
          debug1: Next authentication method: publickey
          debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
          debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
          debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
          debug1: Next authentication method: password

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

          OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
          ...Some sensitive information...
          debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
          debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
          debug1: Enabling compatibility mode for protocol 2.0
          debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
          debug1: SSH2_MSG_KEXINIT sent
          debug1: SSH2_MSG_KEXINIT received
          debug1: kex: server->client aes128-ctr hmac-md5 none
          debug1: kex: client->server aes128-ctr hmac-md5 none
          debug1: sending SSH2_MSG_KEX_ECDH_INIT
          debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
          ...Some sensitive information...
          debug1: ssh_ecdsa_verify: signature correct
          debug1: SSH2_MSG_NEWKEYS sent
          debug1: expecting SSH2_MSG_NEWKEYS
          debug1: SSH2_MSG_NEWKEYS received
          debug1: Roaming not allowed by server
          debug1: SSH2_MSG_SERVICE_REQUEST sent
          debug1: SSH2_MSG_SERVICE_ACCEPT received
          debug1: Authentications that can continue: publickey,password
          debug1: Next authentication method: publickey
          debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
          debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
          debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
          debug1: Next authentication method: password

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

          #下面使用的是GSSAPI-KEYEX來進行驗證
          debug1: Next authentication method: gssapi-keyex
          #但是報錯:沒有可用的Key來交換信息
          debug1: No valid Key exchange context
          #系統接著又使用下一個驗證方法:GSSAPI-WITH-MIC
          debug1: Next authentication method: gssapi-with-mic
          #但遺憾的是,GSSAPI-WITH-MIC方法也失敗。
          #原因:不能確定數字主機地址的域
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
           
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Cannot determine realm for numeric host address
          # 在嘗試幾次后,SSH認證終于放棄了這種驗證。進入下一個驗證:Publickey
          debug1: Next authentication method: publickey

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

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

          下面先放出處理GSSAPI的方法

          禁用GSSAPI認證有兩個方式:客戶端和服務端

          1. 客戶端禁用

          比較簡單,影響的只有單個客戶端用戶,可以用下面的方法實現:

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

          用上面的方法登錄遠程,即可實現禁用GSSAPIAuthentication。

          如果你嫌麻煩,直接配置你ssh客戶端的文件/etc/ssh/ssh_config來達到永久解決這個問題:

          vi /etc/ssh/ssh_config
          ### 找到ssh_config文件里面的GSSAPIAuthentication yes這行
          ### 修改為GSSAPIAuthentication no
          ### 保存ssh_config文件并退出

          這個修改方法是將所有這個機器上的用戶都影響到了,如果你影響面不要那么的廣泛,只要在指定的用戶上實施禁用GSSAPIAuthentication的話,那么你可以在該用戶的目錄下,找到.ssh目錄,在其下面添加config文件,并在文件內添加上面這句,如果沒有這個文件,你也可以直接這么做:

          cat >>~/.ssh/config<<EOF
          GSSAPIAuthentication no
          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連接的日志:

          2014-05-18 23:46:54 Using SSPI from SECUR32.DLL
          2014-05-18 23:46:54 Attempting GSSAPI authentication
          2014-05-18 23:46:54 GSSAPI authentication request refused

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

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

          2、如果你已經配置了Kerberos的情況下

          那么你也可以嘗試下如下的客戶端解決這個問題的方法:

          添加遠程主機的主機名到你本機的host文件中(Linux是/etc/hosts,Windows是系統盤:\Windows\System32\drivers\etc\hosts)。Linux和Windows下都可以添加下面這行。

          ### 注意:下面這樣的IP-Addr要替換成你的遠程機器的IP地址,HostName,自然是主機名
          IP-Addr HostName

          添加完畢之后,保存退出。

          如果你沒有配置Kerberos的話,僅配置這個hosts文件一樣是不能解決問題的,在使用ssh登錄的時候,你可以看到報錯日志會類似下面這樣:

          debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
          debug1: Next authentication method: gssapi-keyex
          debug1: No valid Key exchange context
          debug1: Next authentication method: gssapi-with-mic
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Credentials cache file '/tmp/krb5cc_0' not found
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Credentials cache file '/tmp/krb5cc_0' not found
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
           
           
          debug1: Unspecified GSS failure.  Minor code may provide more information
          Credentials cache file '/tmp/krb5cc_0' not found
           
          debug1: Next authentication method: publickey

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

          3、服務端禁用GSSAPIAuthentication。

          直接到/etc/ssh/sshd_config里面,將GSSAPIAuthentication yes改為no即可了,同時也請注意,你可能也需要將UseDNS這個也修改成UseDNS no(這個要注意,每個系統的默認值不同,此處以CentOS 6為例):

          sudo vi /etc/ssh/sshd_config
          ### 普通用戶權限不夠,需要root權限
          ### 找到GSSAPIAuthentication yes,修改為
          ### GSSAPIAuthentication no
          ### 注意,這里你也需要將UseDNS修改為no,CentOS默認是yes,即使這行已被注釋,你也需要加上
          ### UseDNS no
          ### 有看到人說UseDNS yes不需要修改為UseDNS no,Mitchell測試下來是需要的。
          ### 保存文件,退出

          當禁用之后,我們需要重啟SSH服務來保證新的配置文件被正確應用:

          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遠程登錄時候的認證速度。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:針對HTTPS的理論攻擊正變得實用
          下一篇:沒有下一篇了
          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          欧美做爰视频免费播放_做暖全过程免费的视频_性爱免费视频 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>