通过一次故障分析,彻底解决ssh登录缓慢的问题
最近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 > 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 > 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 > 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 > 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 > 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 > 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和主机名。