SSH登录Linux服务器慢或者登陆错误的解决方法分享

每次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远程登录时候的认证速度。

ssh证书登录错误
错误描述
使用证书ssh链接的时候提示下面错误信息

permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). 可能原因
authorizedkeys 或.ssh的权限太open .ssh 目录改成755 权限 authorizedkeys 改成600
解决
查看日志: cat /var/log/secure 发现 aug 8 17:15:13 centos62 sshd[5624]: authentication refused: bad ownership or modes for file /home/abc/.ssh/authorized_keys 查看.ssh权限为775 .ssh 手动创建的时候是775权限,改成755权限后正常 # chmod 755 ~/.ssh