【转】诊断并解决 SSH 连接慢的方法

每次PuTTY使用SSH登录到远程的Linux进行管理的时候,远程登录的过程都非常慢--输入完用户名之后,非要等到30秒左右才会出来输入密码的提示。在实际处理问题的时候,特别需要快速响应的时候,这种状况着实让人难以忍受。
但后来具体测试了一下,发现这又并非是每种系统的通病,出现问题的机器主要集中的CentOS上,同样的Debian系统,在远程连接的过程就是健步如飞,丝毫没有卡顿犹豫的感觉。这难道是CentOS的问题?

出于好奇,查看了下两个系统在SSH时的差别

CentOS:

  1. ssh -v ssh_test@192.168.128.137
    SSH远程登录的时候显示的信息如下:
  2. OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
  3. ...Some sensitive information...
  4. debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
  5. debug1: match: OpenSSH_5.3 pat OpenSSH_5*
  6. debug1: Enabling compatibility mode for protocol 2.0
  7. debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
  8. debug1: SSH2_MSG_KEXINIT sent
  9. debug1: SSH2_MSG_KEXINIT received
  10. debug1: kex: server->client aes128-ctr hmac-md5 none
  11. debug1: kex: client->server aes128-ctr hmac-md5 none
  12. debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
  13. debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
  14. debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
  15. debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
  16. ...Some sensitive information...
  17. debug1: ssh_rsa_verify: signature correct
  18. debug1: SSH2_MSG_NEWKEYS sent
  19. debug1: expecting SSH2_MSG_NEWKEYS
  20. debug1: SSH2_MSG_NEWKEYS received
  21. debug1: Roaming not allowed by server
  22. debug1: SSH2_MSG_SERVICE_REQUEST sent
  23. debug1: SSH2_MSG_SERVICE_ACCEPT received
  24. debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
  25. debug1: Next authentication method: gssapi-keyex
  26. debug1: No valid Key exchange context
  27. debug1: Next authentication method: gssapi-with-mic
  28. debug1: Unspecified GSS failure. Minor code may provide more information
  29. Cannot determine realm for numeric host address
  30. debug1: Unspecified GSS failure. Minor code may provide more information
  31. Cannot determine realm for numeric host address
  32. debug1: Unspecified GSS failure. Minor code may provide more information
  33. debug1: Unspecified GSS failure. Minor code may provide more information
  34. Cannot determine realm for numeric host address
  35. debug1: Next authentication method: publickey
  36. debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
  37. debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
  38. debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
  39. debug1: Next authentication method: password
    而Debian使用同样的命令测试的结果为:
  40. OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
  41. ...Some sensitive information...
  42. debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
  43. debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
  44. debug1: Enabling compatibility mode for protocol 2.0
  45. debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
  46. debug1: SSH2_MSG_KEXINIT sent
  47. debug1: SSH2_MSG_KEXINIT received
  48. debug1: kex: server->client aes128-ctr hmac-md5 none
  49. debug1: kex: client->server aes128-ctr hmac-md5 none
  50. debug1: sending SSH2_MSG_KEX_ECDH_INIT
  51. debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  52. ...Some sensitive information...
  53. debug1: ssh_ecdsa_verify: signature correct
  54. debug1: SSH2_MSG_NEWKEYS sent
  55. debug1: expecting SSH2_MSG_NEWKEYS
  56. debug1: SSH2_MSG_NEWKEYS received
  57. debug1: Roaming not allowed by server
  58. debug1: SSH2_MSG_SERVICE_REQUEST sent
  59. debug1: SSH2_MSG_SERVICE_ACCEPT received
  60. debug1: Authentications that can continue: publickey,password
  61. debug1: Next authentication method: publickey
  62. debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
  63. debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
  64. debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
  65. debug1: Next authentication method: password
    从上面可以看到,在CentOS中,系统使用了publickey,gssapi-keyex,gssapi-with-mic,和password来进行认证(上面颜色标记行,23行),而Debian此时则使用了Publickey和password两种。在连接CentOS的时候,在23行处花费了相当多的时间。我们在那里开始往下看,就能非常清楚的看到下面的信息:
  66. #下面使用的是GSSAPI-KEYEX来进行验证
  67. debug1: Next authentication method: gssapi-keyex
  68. #但是报错:没有可用的Key来交换信息
  69. debug1: No valid Key exchange context
  70. #系统接着又使用下一个验证方法:GSSAPI-WITH-MIC
  71. debug1: Next authentication method: gssapi-with-mic
  72. #但遗憾的是,GSSAPI-WITH-MIC方法也失败。
  73. #原因:不能确定数字主机地址的域
  74. debug1: Unspecified GSS failure. Minor code may provide more information
  75. Cannot determine realm for numeric host address
  76. debug1: Unspecified GSS failure. Minor code may provide more information
  77. Cannot determine realm for numeric host address
  78. debug1: Unspecified GSS failure. Minor code may provide more information
  79. debug1: Unspecified GSS failure. Minor code may provide more information
  80. Cannot determine realm for numeric host address
  81. # 在尝试几次后,SSH认证终于放弃了这种验证。进入下一个验证:Publickey
  82. 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文件,并在文件内添加上面这句,如果没有这个文件,你也可以直接这么做:
  5. cat >>~/.ssh/config<<EOF
  6. GSSAPIAuthentication no
  7. 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-18 23:46:54 Using SSPI from SECUR32.DLL
  2. 2014-05-18 23:46:54 Attempting GSSAPI authentication
  3. 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下都可以添加下面这行。

  1. `### 注意:下面这样的IP-Addr要替换成你的远程机器的IP地址,HostName,自然是主机名

    IP-Addr HostName`

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

如果你没有配置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服务来保证新的配置文件被正确应用:
  9. 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://www.ioser.net/index.php/archives/104/
1 + 1 =
1 评论
    Ai Chrome 77 Windows 10
    2019年10月21日 回复

    (滑稽