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

每次PuTTY使用SSH登录到远程的Linux进行管理的时候，远程登录的过程都非常慢——输入完用户名之后，非要等到30秒左右才会出来输入密码的提示。在实际处理问题的时候，特别需要快速响应的时候，这种状况着实让人难以忍受。

但后来具体测试了一下，发现这又并非是每种系统的通病，出现问题的机器主要集中的CentOS上，同样的Debian系统，在远程连接的过程就是健步如飞，丝毫没有卡顿犹豫的感觉。这难道是CentOS的问题？

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

CentOS：



    

  1. ssh -v ssh_test@192.168.128.137
    2. 



SSH远程登录的时候显示的信息如下：




    

  1. OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
    2. 

  2. ...Some sensitive information...
    3. 

  3. debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
    4. 

  4. debug1: match: OpenSSH_5.3 pat OpenSSH_5*
    5. 

  5. debug1: Enabling compatibility mode for protocol 2.0
    6. 

  6. debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
    7. 

  7. debug1: SSH2_MSG_KEXINIT sent
    8. 

  8. debug1: SSH2_MSG_KEXINIT received
    9. 

  9. debug1: kex: server->client aes128-ctr hmac-md5 none
    10. 

  10. debug1: kex: client->server aes128-ctr hmac-md5 none
    11. 

  11. debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    12. 

  12. debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    13. 

  13. debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    14. 

  14. debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    15. 

  15. ...Some sensitive information...
    16. 

  16. debug1: ssh_rsa_verify: signature correct
    17. 

  17. debug1: SSH2_MSG_NEWKEYS sent
    18. 

  18. debug1: expecting SSH2_MSG_NEWKEYS
    19. 

  19. debug1: SSH2_MSG_NEWKEYS received
    20. 

  20. debug1: Roaming not allowed by server
    21. 

  21. debug1: SSH2_MSG_SERVICE_REQUEST sent
    22. 

  22. debug1: SSH2_MSG_SERVICE_ACCEPT received
    23. 

  23. debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
    24. 

  24. debug1: Next authentication method: gssapi-keyex
    25. 

  25. debug1: No valid Key exchange context
    26. 

  26. debug1: Next authentication method: gssapi-with-mic
    27. 

  27. debug1: Unspecified GSS failure.  Minor code may provide more information
    28. 

  28. Cannot determine realm for numeric host address
    29. 

  29.  
    30. 

  30. debug1: Unspecified GSS failure.  Minor code may provide more information
    31. 

  31. Cannot determine realm for numeric host address
    32. 

  32.  
    33. 

  33. debug1: Unspecified GSS failure.  Minor code may provide more information
    34. 

  34.  
    35. 

  35.  
    36. 

  36. debug1: Unspecified GSS failure.  Minor code may provide more information
    37. 

  37. Cannot determine realm for numeric host address
    38. 

  38.  
    39. 

  39. debug1: Next authentication method: publickey
    40. 

  40. debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
    41. 

  41. debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
    42. 

  42. debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
    43. 

  43. debug1: Next authentication method: password
    44. 



而Debian使用同样的命令测试的结果为：




    

  1. OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
    2. 

  2. ...Some sensitive information...
    3. 

  3. debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
    4. 

  4. debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH*
    5. 

  5. debug1: Enabling compatibility mode for protocol 2.0
    6. 

  6. debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
    7. 

  7. debug1: SSH2_MSG_KEXINIT sent
    8. 

  8. debug1: SSH2_MSG_KEXINIT received
    9. 

  9. debug1: kex: server->client aes128-ctr hmac-md5 none
    10. 

  10. debug1: kex: client->server aes128-ctr hmac-md5 none
    11. 

  11. debug1: sending SSH2_MSG_KEX_ECDH_INIT
    12. 

  12. debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    13. 

  13. ...Some sensitive information...
    14. 

  14. debug1: ssh_ecdsa_verify: signature correct
    15. 

  15. debug1: SSH2_MSG_NEWKEYS sent
    16. 

  16. debug1: expecting SSH2_MSG_NEWKEYS
    17. 

  17. debug1: SSH2_MSG_NEWKEYS received
    18. 

  18. debug1: Roaming not allowed by server
    19. 

  19. debug1: SSH2_MSG_SERVICE_REQUEST sent
    20. 

  20. debug1: SSH2_MSG_SERVICE_ACCEPT received
    21. 

  21. debug1: Authentications that can continue: publickey,password
    22. 

  22. debug1: Next authentication method: publickey
    23. 

  23. debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa
    24. 

  24. debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa
    25. 

  25. debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa
    26. 

  26. debug1: Next authentication method: password
    27. 



从上面可以看到，在CentOS中，系统使用了publickey，gssapi-keyex，gssapi-with-mic，和password来进行认证（上面颜色标记行，23行），而Debian此时则使用了Publickey和password两种。在连接CentOS的时候，在23行处花费了相当多的时间。我们在那里开始往下看，就能非常清楚的看到下面的信息：




    

  1. #下面使用的是GSSAPI-KEYEX来进行验证
    2. 

  2. debug1: Next authentication method: gssapi-keyex
    3. 

  3. #但是报错：没有可用的Key来交换信息
    4. 

  4. debug1: No valid Key exchange context
    5. 

  5. #系统接着又使用下一个验证方法：GSSAPI-WITH-MIC
    6. 

  6. debug1: Next authentication method: gssapi-with-mic
    7. 

  7. #但遗憾的是，GSSAPI-WITH-MIC方法也失败。
    8. 

  8. #原因：不能确定数字主机地址的域
    9. 

  9. debug1: Unspecified GSS failure.  Minor code may provide more information
    10. 

  10. Cannot determine realm for numeric host address
    11. 

  11.  
    12. 

  12. debug1: Unspecified GSS failure.  Minor code may provide more information
    13. 

  13. Cannot determine realm for numeric host address
    14. 

  14.  
    15. 

  15. debug1: Unspecified GSS failure.  Minor code may provide more information
    16. 

  16.  
    17. 

  17.  
    18. 

  18. debug1: Unspecified GSS failure.  Minor code may provide more information
    19. 

  19. Cannot determine realm for numeric host address
    20. 

  20. # 在尝试几次后，SSH认证终于放弃了这种验证。进入下一个验证：Publickey
    21. 

  21. debug1: Next authentication method: publickey
    22. 



除了这个方法还有其他方法么？这个自然是有的，CentOS其实就已经提供给我们一个解决方案了——使用ssh远程登录的时候禁用GSSAPI验证。当然，还有一个问题不得不注意，如果你的机器上启用了UseDNS的话，需要一并关闭，具体可参见最后的说明。


从错误可以看出应该是和主机域相关的问题——应该是无法确认IP对应的域，因此会出现这个问题。GSSAPI主要是基于Kerberos的，因此要解决这个问题也就变得要系统配置有Kerberos，这对于没有Kerberos的筒子们来说，配置个Kerberos就为了解决个登录延时问题，似乎不是个明智的决定——特别是在生产环境中！最小化满足需求才是王道。


下面先放出处理GSSAPI的方法


禁用GSSAPI认证有两个方式：客户端和服务端


1. 客户端禁用


比较简单，影响的只有单个客户端用户，可以用下面的方法实现：




    

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



用上面的方法登录远程，即可实现禁用GSSAPIAuthentication。


如果你嫌麻烦，直接配置你ssh客户端的文件/etc/ssh/ssh_config来达到永久解决这个问题：




    

  1. vi /etc/ssh/ssh_config
    2. 

  2. ### 找到ssh_config文件里面的GSSAPIAuthentication yes这行
    3. 

  3. ### 修改为GSSAPIAuthentication no
    4. 

  4. ### 保存ssh_config文件并退出
    5. 



这个修改方法是将所有这个机器上的用户都影响到了，如果你影响面不要那么的广泛，只要在指定的用户上实施禁用GSSAPIAuthentication的话，那么你可以在该用户的目录下，找到.ssh目录，在其下面添加config文件，并在文件内添加上面这句，如果没有这个文件，你也可以直接这么做：




    

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

  2. GSSAPIAuthentication no
    3. 

  3. EOF
    4. 



使用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. 

  2. 2014-05-18 23:46:54 Attempting GSSAPI authentication
    3. 

  3. 2014-05-18 23:46:54 GSSAPI authentication request refused
    4. 



恩，上面基本上将客户端禁止GSSAPIAuthentication的方法罗列了一下。


注意：上面这些方法是比较通用的。


2、如果你已经配置了Kerberos的情况下


那么你也可以尝试下如下的客户端解决这个问题的方法：


添加远程主机的主机名到你本机的host文件中（Linux是/etc/hosts，Windows是系统盘:\Windows\System32\drivers\etc\hosts）。Linux和Windows下都可以添加下面这行。




    

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



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


如果你没有配置Kerberos的话，仅配置这个hosts文件一样是不能解决问题的，在使用ssh登录的时候，你可以看到报错日志会类似下面这样：




    

  1. debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
    2. 

  2. debug1: Next authentication method: gssapi-keyex
    3. 

  3. debug1: No valid Key exchange context
    4. 

  4. debug1: Next authentication method: gssapi-with-mic
    5. 

  5. debug1: Unspecified GSS failure.  Minor code may provide more information
    6. 

  6. Credentials cache file '/tmp/krb5cc_0' not found
    7. 

  7.  
    8. 

  8. debug1: Unspecified GSS failure.  Minor code may provide more information
    9. 

  9. Credentials cache file '/tmp/krb5cc_0' not found
    10. 

  10.  
    11. 

  11. debug1: Unspecified GSS failure.  Minor code may provide more information
    12. 

  12.  
    13. 

  13.  
    14. 

  14. debug1: Unspecified GSS failure.  Minor code may provide more information
    15. 

  15. Credentials cache file '/tmp/krb5cc_0' not found
    16. 

  16.  
    17. 

  17. debug1: Next authentication method: publickey
    18. 



这个错误我在刚开始的时候也犯了的，需要注意。


3、服务端禁用GSSAPIAuthentication。


直接到/etc/ssh/sshd_config里面，将GSSAPIAuthentication yes改为no即可了，同时也请注意，你可能也需要将UseDNS这个也修改成UseDNS no（这个要注意，每个系统的默认值不同，此处以CentOS 6为例）：




    

  1. sudo vi /etc/ssh/sshd_config
    2. 

  2. ### 普通用户权限不够，需要root权限
    3. 

  3. ### 找到GSSAPIAuthentication yes，修改为
    4. 

  4. ### GSSAPIAuthentication no
    5. 

  5. ### 注意，这里你也需要将UseDNS修改为no，CentOS默认是yes，即使这行已被注释，你也需要加上
    6. 

  6. ### UseDNS no
    7. 

  7. ### 有看到人说UseDNS yes不需要修改为UseDNS no，Mitchell测试下来是需要的。
    8. 

  8. ### 保存文件，退出
    9. 



当禁用之后，我们需要重启SSH服务来保证新的配置文件被正确应用：




    

  1. service sshd restart
    2. 



这个时候，再次使用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远程登录时候的认证速度。


原文发布时间为：2015-07-20











本文来自合作伙伴“Linux中国
				


				
时间： 2024-08-04 08:57:21

		
		


		


	

	
	

		


		
诊断并解决 SSH 连接慢的方法诊断并解决 SSH 连接慢的方法的相关文章


								

		

			

                win7系统无法上网提示“本地连接没有有效的IP配置”解决方法
			

		

		

									

				  win7系统操作过程中总是遇到一些故障问题,最近有用户发现无法连接网络,使用win7系统内置windows网络诊断工具,使用诊断工具诊断后发现原因是"本地连接没有有效的IP配置",怎么回事呢?其实出现"本地连接没有有效的IP配置"通常是由于本地连接配置不正常导致,我们手工进行禁用再启用就可以解决问题了.下面一起看看详细解决步骤. 操作步骤: 1.点击开始菜单,然后进入到控制面板中; 2.在控制面板中点击"查看网络状态和任务"; 3.然后点击&			

		

	

				

		

			

                win8.1系统无法连接无线必须休眠唤醒电脑后才能连接解决方法
			

		

		

									

				  操作win8.1系统过程中会遇到各种奇葩问题,比如最近有用户反馈笔记本Win8.1系统开机后无线连接不上,尝试多次之后还是无效,必须要休眠一下电脑唤醒后才能连接,每次这样会比较麻烦,那么该如何解决此问题呢?出现这样的问题可能是无线网卡的节电功能不正常触发导致的.大家不要太担心,如果你也遇到电脑无法正常连接无线的情况不妨试试下面的方法. 具体步骤: 1.按下WIN+X组合键,然后打开设备管理器; 2.在设备管理器中,找到无线网卡选项,双击打开属性; 3.电源管理那个选项卡,去掉允许计算机关闭这			

		

	

				

		

			

                xp/win7/win8系统电脑连接投影设备后无声音的解决方法
			

		

		

									

				  xp/win7/win8系统电脑连接投影设备后无声音的解决方法.开会或办公时会使用到投影设备,可以在更大的屏幕上观看电脑内容,方便大家观看.但是有时候当插入外接屏幕的高清转换线时,xp/win7/win8系统电脑会发生没声音,该如何解决呢?针对电脑连接投影设备后无声音的问题,只要参考下面教程进行一些简单设置便可解决问题了,下面看看详细教程内容吧. 具体方法如下: 1.单击 "我的电脑" , 选择 管理; 2.选择 "设备管理器" --> "声音.			

		

	

				

		

			

                连接池和 Timeout expired异常解决方法
			

		

		

									

				连接池和 timeout expired异常解决方法 你需要保证你每次调用连接的同时都在使用过后通过close()或dispose()对其执行了关闭.最简单的办法就是使用using,将你的连接泄漏方法修改成如下面的代码样式: public void doesnotleakconnections()     {            using (sqlconnection sqlconnection1 = new sqlconnection("server=.sqlexpress ;integr			

		

	

				

		

			

                win7连接VPN时提示800错误怎么办 连接VPN时提示错误800解决方法
			

		

		

									

				win7连接VPN时提示错误800解决方法 1.重启电脑并关闭网络连接,然后将软件和硬件的防火墙关闭掉,电脑杀毒软件自带的防火墙和路由器等设备的防火墙. 2.将VPN设备端口1723上的TCP协议中的窗口大小修改为0. 3.重新配置VPN主机的网络设置. 4.如果无法解决,建议联系设备制造商进行解决. 以上就是关于win7系统设置vpn虚拟连接教程介绍了,通过以上分享后,遇到相同问题的用户,请参照以上方法设置吧.			

		

	

				

		

			

                电脑中无法连接阿里云远程桌面的解决方法
			

		

		

									

				  方法一:之前连接正常,突然无法连接 1.这种情况只能重启服务器,登录阿里云账号,进入控制台; 2.选择实例,选择服务所在的区域,点击实例后面的管理; 3.直接重启阿里云服务器或者停止后再重新启动; 4.如果不重启,则点击更多--连接到终端,和连接远程桌面一样,通过这里直接进行连接,不过需要输入管理密码. 方法二:一直无法连接 1.这种情况一般是由于服务器端没有开启远程桌面功能,或者是某些优化软件将远程桌面禁用了; 2.打开控制面板--系统和安全--允许远程访问; 3.勾选"允许远程连接到此计			

		

	

				

		

			

                Win7连接Windows XP网络打印机失败？windows无法连接到打印机拒绝访问解决方法
			

		

		

									

				故障现象: 我们在利用windows 7连接xp网络打开机时提示 "windows无法连接到打印机拒绝访问 或者 windows无法连接到打印机本地后台打印程序服务没有运行"的提示. 原因分析: 出现这种问题其实是打印机驱动程序问题,可给你只安装了windows xp系统驱动程序了,而没有安装windows7驱动程序,因你你安装xp系统驱动程序只能使用在xp系统中哦,它并不支持windwos 7系统哦. 解决方案: 1. 现在我们在windows7系统中点击"开始---控制面			

		

	

				

		

			

                SSH服务的几个超时参数 以及 类似DDOS攻击的方法
			

		

		

									

				背景 sshd是Linux的一个常用的网络连接的服务,通常被用来远程连接,管理服务器. 一般我们很少去配置sshd,本文要给大家分享几个sshd的参数,有超时参数,有触发拒绝连接的参数等等. 如果你哪天遇到类似的问题,也行能帮助你找到问题的根源. sshd 空闲超时参数 man sshd_config 连续接收到几次sshd发送给客户端的alive包之后,中断该SSH会话. ClientAliveCountMax Sets the number of client alive messages			

		

	

				

		

			

                Win7本地连接IPV4无访问权限怎么解决
			

		

		

									

				  Win7本地连接IPV4无访问权限的解决方法. 步骤如下: 一.本地连接ipv4无网络访问权限 1.首先,进行如下的操作: (1).点击"详细信息",然后点击本地连接状态中的详细信息选项. (2).查看"IPv4地址". 二.结果分析: 1.如果显示:169.X.X.X的话,说明是电脑与路由器之间的通信(连接)有问题,电脑没有从路由器上获取到IP地址信息. 2.本地连接中IPv4地址是以:169开头的IP. 解决办法: (1).检查电脑与路由器之间的连接是否正确