通过一次故障分析，彻底解决ssh登录缓慢的问题

发表于： 2018年12月31日 2019年2月11日
分类： Linux/Unix

最近ssh登录系统，总要等几秒钟，一开始以为只是个别的服务器，没太注意。后来发现很多的服务器都是这样。
决定好好找找原因。
转载本站文章请注明出处：黄海兵haibing.org

开始排查：
1、ssh加上-vvv,显示debug过程
#ssh -vvv 192.168.1.115

............
debug3: Wrote 64 bytes for a total of 1277
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.115.

到这里时会停顿几秒，说明这里有问题。
我们看最后一句：
debug3: Trying to reverse map address 192.168.1.115.

是在反向解析这个192.168.1.115这个IP地址。
说明是在请求DNS来进行反向解析这个IP地址。
转载本站文章请注明出处：黄海兵haibing.org

我们可以在要登录的服务端使用tcpdump来抓包分析。
# tcpdump -i eth1 port 53

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:10:20.485995 IP 192.168.1.115.44611 &gt; 218.85.157.99.domain: 46922+ PTR? 114.1.168.192.in-addr.arpa. (44)
13:10:20.537832 IP 192.168.1.115.58714 &gt; 218.85.157.99.domain: 39680+ PTR? 99.157.85.218.in-addr.arpa. (44)
13:10:25.502103 IP 192.168.1.115.44611 &gt; 218.85.157.99.domain: 46922+ PTR? 114.1.168.192.in-addr.arpa. (44)
13:10:25.546227 IP 192.168.1.115.58714 &gt; 218.85.157.99.domain: 39680+ PTR? 99.157.85.218.in-addr.arpa. (44)
13:10:30.564027 IP 192.168.1.115.50390 &gt; 218.85.157.99.domain: 33178+ PTR? 115.1.168.192.in-addr.arpa. (44)
13:10:35.575683 IP 192.168.1.115.50390 &gt; 218.85.157.99.domain: 33178+ PTR? 115.1.168.192.in-addr.arpa. (44)

可以看到，使用ssh登录时，会通过DNS去反解析IP。这里就花了20s的时间。

之所以使用到反向解析，主要是通过IP和主机名对应来防止伪装客户端。
转载本站文章请注明出处：黄海兵haibing.org

2、确认DNS是否正常
使用的是福建电信的DNS：218.85.157.99
首先是使用ping测试：
#ping 218.85.157.99
PING 218.85.157.99 (218.85.157.99) 56(84) bytes of data.
64 bytes from 218.85.157.99: icmp_seq=1 ttl=56 time=4.71 ms
64 bytes from 218.85.157.99: icmp_seq=2 ttl=56 time=4.71 ms
64 bytes from 218.85.157.99: icmp_seq=3 ttl=56 time=4.58 ms

ping是正常的。

使用nslookup解析域名：
#nslookup www.baidu.com
Server: 218.85.157.99
Address: 218.85.157.99#53

Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 14.215.177.38
Name: www.a.shifen.com
Address: 14.215.177.39

解析域名也正常。

反解析IP：
#nslookup 14.215.177.38
Server: 218.85.157.99
Address: 218.85.157.99#53

** server can’t find 38.177.215.14.in-addr.arpa.: NXDOMAIN

反解析IP也能很快的提示找不到。

反解析本机私有段的IP：
# nslookup 192.168.1.115
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached

这里出现超时。
可能是电信的DNS反解析私有IP段有修改什么策略，造成反解析私有IP段都会超时。因为以前都是正常使用的。

确定是DNS的问题后，就比较好解决了。
转载本站文章请注明出处：黄海兵haibing.org

最好最快捷的办法是清除DNS地址，或者修改成一个正常的DNS，这个问题即可解决。
还可以禁用ssh的DNS解析功能，来解决这个问题。

3、清除DNS或者修改DNS地址
直接修改/etc/resolve.conf
有的可能是直接写到网卡配置文件中了，也要修改

4、关闭ssh的DNS解析功能
修改/etc/ssh/sshd_config
把其中的#UseDNS yes修改为UseDNS no

当DNS有问题时，GSSAPIAuthentication功能会受到影响，所以这个也要关闭：
把GSSAPIAuthentication yes修改为GSSAPIAuthentication no

重启sshd服务
#service sshd restart

客户端的ssh_config也要修改：
#vim /etc/ssh/ssh_config
Host *
GSSAPIAuthentication no

注意：
一般通过以上方法关闭GSSAPIAuthentication和UseDNS即可解决SSH登录慢的问题，如果还没解决，接着往下看。

SSH配置文件中的 RhostsRSAAuthentication, HostbasedAuthentication，AllowUsers，DenyUsers等一旦开启都会要求进行DNS反向查询。
这么说吧，基本上只要出现有IP的地方，一般都会需要DNS进行反向解析。
所以如果有配置hosts.allow/hosts.deny的话，就算关掉了GSSAPIAuthentication和UseDNS，也是没用的，SSH登录时还是会去反向解析IP地址。

如果有遇到这种情况，只能去掉DNS或者修改为一个正常的DNS。
或者直接在要登录的服务器的hosts文件里直接填上对方的IP和主机名。

haibing

101