如何解决SSH连接Linux服务器变慢的问题

大致是有以下几种原因：

1、SERVER的SSHD会去DNS查找访问的CLIENT IP的HOSTNAME，如果DNS不可用或者没有相关记录，就会消耗一段时间。

2、在authentication gssapi-with-mic有时候也会消耗一段时间

一、测试查找具体原因：

1、使用ssh -v host进行debug

<span style="font-size:18px"># ssh -v 192.168.100.10</span>

然后就会输出一大堆debug，通过debug信息就可以看到连接到什么地方被耽搁了

比如会显示如下信息：

debug1: Next authentication method: gssapi-with-mic

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

No credentials cache found

2、检测连接时间

<span style="font-size:18px"># time ssh root@192.168.100.10 exit</span>

二、解决方法（建议一个个设置，因为每个人连接慢的原因都不一样）：

注意：修改之后记得重启sshd服务

# service sshd restart

1、关闭DNS反向解析

在linux中，默认就是开启了SSH的反向DNS解析,这个会消耗大量时间，因此需要关闭。

# vi /etc/ssh/sshd_config

UseDNS=no

在配置文件中，虽然UseDNS yes是被注释的，但默认开关就是yes

2、关闭SERVER上的GSS认证

在authentication gssapi-with-mic有很大的可能出现问题，因此关闭GSS认证可以提高ssh连接速度。

# vi /etc/ssh/sshd_config

GSSAPIAuthentication no

3、修改server上nsswitch.conf文件

# vi /etc/nsswitch.conf

找到

hosts： files dns

改为

hosts：files

hosts： files dns这一行含义是对于访问的主机进行域名解析的顺序，是先访问file，也就是/etc/hosts文件，如果hosts中没有记录域名，则访问dns，进行域名解析，如果dns也无法访问，就会等待访问超时后返回，因此等待时间比较长。

注意：如果SERVER需要通过域名访问其他服务器，则需要保留此行。

4、修改SERVER上resolv.conf文件

4.1、删除/etc/resolv.conf中所有不使用的IP。

4.2、把nameserver全部删除，问题也能解决，但是服务器就无法上网了。

4.3、如果SERVER曾经配置过双网卡，则在该文件中会有一行目前不使用的IP地址，删除该行即可。

5、修改SERVER上hosts文件

在SERVER上/etc/hosts文件中把客户端的IP和HOSTNAME加入

6、打开SERVER上的IgnoreRhosts参数

IgnoreRhosts参数可以忽略以前登录过主机的记录，设置为yes后可以极大的提高连接速度

# vi /etc/ssh/sshd_config

IgnoreRhosts yes

----------------以上的均在SERVER上设置，以下的均在CLIENT上设置-------------------

7、修改客户端的hosts文件

将目标SERVER的IP和域名加上去,使得本机的DNS服务能解析目标地址。

# vi /etc/hosts

192.168.100.11 doiido.com

注：hosts文件格式为'目标SERVER_IP 目标SERVER_NAME'。但是使用这个方法有一个弊端，如果需要给每台SERVER都添加一个域名解析。

8、修改客户端配置文件ssh_conf（注意，不是sshd_conf）

# vi /etc/ssh/ssh_conf

找到

GSSAPIAuthentication yes

改为

GSSAPIAuthentication no

查看/var/log目录下messages、secure文件大小：

一般是这两个文件比较大，导致连接慢

清空/var/log/messages、/var/log/secure内容：

查询打开/var/log/messages文件的进程的进程ID(PID)：

结束生成messages的进程：

清空日志并重启：

首先是抓包，步骤如下

在Linux服务器上启动抓包。

从笔记本SSH到Linux服务器，输入用户名并回车。

等待10秒左右，直到登录界面提示输入密码。

停止抓包。

这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量，不用过滤也可以分析，不过我们最好在做实验时就养成过滤的习惯，以适应生产环境中抓到的包。因为我们是通过SSH协议登录的，所以可以直接用“ssh”来过滤，如图所示。SSH包都是加密了的，因此我们看不出每个包代表了什么意思，不过这并不影响分析。从图2中可以看到，21号包和25号包之间恰好就相隔10秒。

这两个包之间所发生的事件，可能就是导致这个现象的原因。于是我再用“frame.number>21 &&frame.number<25”过滤，

分析

从图中可以看到，Linux服务器当时正忙着向DNS服务器查询10.32.200.23的PTR记录（即反向解析），试图获得这个IP地址所对应的域名。该IP属于我们测试所用的笔记本，但由于DNS服务器上没有它的PTR记录，所以两次查询都等了5秒钟还没结果，总共浪费了10秒钟。

我们由此可以推出，这台Linux服务器在收到SSH访问请求时，会先查询该客户端IP所对应的PTR记录。假如经过5秒钟还没有收到回复，就再发一次查询。如果第二次查询还是等了5秒还没回复，就彻底放弃查询。我们甚至可以进一步猜测，如果DNS查询能成功，就不用白等那10秒钟了。

为了验证这个猜测，我在DNS服务器中添加了10.32.200.23的PTR记录，然后再次登录。

这一次果然立即登录进去了。从图的Wireshark截屏可见，DNS查询是成功的，所以21号包和26号包之间几乎是没有时间停顿的。

结果

明白了DNS查询就是问题的起因，接下来就知道怎么进一步研究了。只要在Google搜索“ssh dns”，第一页出来的链接都是关于这个问题的。随便挑几篇阅读一下，就连我这样的Linux初学者都能把这个问题研究透了。原来这个行为是定义在“/etc/ssh/sshd_config”文件中的，默认配置是这样的：

[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usedns #UseDNS yes

改成下面这样就可以解决了，不用去动DNS服务器上的配置：

[root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns UseDNS no

---