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

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

出于好奇，查看了下兩個系統(tǒng)在SSH時的差別
CentOS：

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(102410248192) 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使用同樣的命令測試的結(jié)果為：

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中，系統(tǒng)使用了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
#系統(tǒng)接著又使用下一個驗證方法：GSSAPI-WITH-MIC
debug1: Next authentication method: gssapi-with-mic
#但遺憾的是，GSSAPI-WITH-MIC方法也失敗。
#原因：不能確定數(shù)字主機地址的域
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其實就已經(jīng)提供給我們一個解決方案了——使用ssh遠程登錄的時候禁用GSSAPI驗證。當然，還有一個問題不得不注意，如果你的機器上啟用了UseDNS的話，需要一并關(guān)閉，具體可參見最后的說明。

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

下面先放出處理GSSAPI的方法
禁用GSSAPI認證有兩個方式：客戶端和服務端

1. 客戶端禁用
比較簡單，影響的只有單個客戶端用戶，可以用下面的方法實現(xiàn)：

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

上面這些文件是在客戶端，不是服務端的。也就是說，要修改這個文件，你的客戶端也要是Linux才行。

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

如果沒有關(guān)閉PuTTY的GSSAPIAuthentication，你可以在連接的窗口右鍵（或：Ctrl + 右鍵）查看日志，可以發(fā)現(xiàn)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、如果你已經(jīng)配置了Kerberos的情況下
那么你也可以嘗試下如下的客戶端解決這個問題的方法：

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

如果你沒有配置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（這個要注意，每個系統(tǒng)的默認值不同，此處以CentOS 6為例）：

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

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

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

ssh證書登錄錯誤
錯誤描述
使用證書ssh鏈接的時候提示下面錯誤信息

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). 可能原因
authorizedkeys 或.ssh的權(quán)限太open .ssh 目錄改成755 權(quán)限 authorizedkeys 改成600
解決
查看日志: cat /var/log/secure 發(fā)現(xiàn) Aug 8 17:15:13 CentOS62 sshd[5624]: Authentication refused: bad ownership or modes for file /home/abc/.ssh/authorized_keys 查看.ssh權(quán)限為775 .ssh 手動創(chuàng)建的時候是775權(quán)限,改成755權(quán)限后正常 # chmod 755 ~/.ssh