背景
大家工作时,少不了ssh登录各个服务器,我这边手里也有很多服务器,有一些登录很快就进去了,有些要卡半天才能进去。之前以为是公司网络问题,每次也就忍了,这次突然不想忍了,决定定位一下。
我这边的服务器是10.80.121.46。因为这个问题是可复现的,算是个好问题,于是在本地开了wireshark,ssh登录,看看能不能看出端倪。
- host 10.80.121.46 and tcp port 22
复制代码
可以看到,服务端在00:13,发了第一个消息过来;过了20s,发了第二个消息过来。
总的来说,应该是服务端问题。
定位过程
看日志
由于是ssh这种加密了的协议,抓包也看不出个啥。所以我首先的思路是看看sshd这个服务端进程的日志。sshd是systemd管理的,所以看看状态先。
这种的话,一般也能看到最新的日志,如果要看完整的日志,可以用如下命令:
- journalctl -u sshd
- ps: journalctl -u sshd -f 可以像tailf那样持续跟踪日志
复制代码
但是,发现只有info级别的日志,也看不出什么特别:
- Apr 03 15:27:30 nginx2 sshd[87616]: Accepted password for root from 10.0.235.72 port 11481 ssh2
复制代码
接下来,又看了下其他日志:
/var/log/messages:
- Apr 3 15:27:30 year-account-nginx2 systemd-logind: New session 13336 of user root.
- Apr 3 15:27:30 year-account-nginx2 systemd: Started Session 13336 of user root.
复制代码
/var/log/secure:
- Apr 3 15:27:30 year-account-nginx2 sshd[87616]: Accepted password for root from 10.0.235.72 port 11481 ssh2
- Apr 3 15:27:30 year-account-nginx2 sshd[87616]: pam_unix(sshd:session): session opened for user root by (uid=0)
复制代码
反正看了好些日志,没啥用,这边上个链接,讲linux下的各种日志。
https://www.plesk.com/blog/featured/linux-logs-explained/
https://www.eurovps.com/blog/imp ... must-be-monitoring/
开启debug日志
上网查了下,怎么开启sshd的debug级别日志,结论如下:
- vim /etc/ssh/sshd_config 加一行:
- LogLevel DEBUG
复制代码
这个LogLevel的取值有哪些呢,具体可以在机器上执行:
没想到取值还有更逆天的:
我之前就是在debug级别下测试的,然后看日志:
看到出现了20s的间隔,但是,还是没有什么错误或者警告。当时,我就开始上网查了,但是这次,咱们要不试试把日志级别弄成DEBUG3:
这里日志细了一些,但还是看不太出来啥问题。这个10.0.235.72,是我本机windows的ip。
服务端dns抓包
经过上网冲浪,发现很多文章提到了一点,就是sshd会拿着我们客户端的ip,去dns 服务器查询ip对应的主机名(域名)。很明显,我这个ip,肯定是没什么域名的。大概率是这个原因,但是基于严谨的角度考虑,我还是先找找证据。
dns服务器对外的端口是53,所以我抓的就是这个端口的网络包:
可以发现,本机是给两个dns服务器发请求的,分别是8.8.8.8 8.8.4.4
看下机器的dns服务器配置:
- vim /etc/resolv.conf
- nameserver 8.8.8.8
- nameserver 8.8.4.4
复制代码
不知道为啥是这个地址。
测试了端口通不通,发现tcp不通,udp不知道咋测(试了下netcat、nmap,没太弄懂)
ping也不通,不知道是真不通,还是对端禁ping了。
这些都不重要,重要的是,这个报文也不知道是啥意思,看起来和我的问题没什么关系。
trace排查
暂时放下dns这块,准备strace试试,反正,死马当活马医。
strace这个一般用得少,选项记不住,一开始就这么试试:
- netstat -nltp|grep 22
- tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 93585/sshd
- tcp 0 0 0.0.0.0:4822 0.0.0.0:* LISTEN 31633/nginx: master
- tcp6 0 0 :::22 :::* LISTEN 93585/sshd
复制代码
拿到sshd pid为93585,开启strace:
但是啥也没看出来。
找了下以前笔记,加了几个选项:
- strace -p 121920 -s 1000 -t -e trace=network,file,desc,process
- -s: 字符串显示1000个字符串,不截断(默认是32,会看不全)
- -t:显示时间
- -e trace=network,file,desc,process,监控网络、文件、文件描述符、进程相关的系统调用
复制代码
这次信息多一点,还是啥都看不出来。
上网查
没法了,把之前dns抓的包拿下来用wireshark分析分析。
这个dns查询,有点看不懂,直接拿关键字搜了下,大家看如下链接吧:
https://www.cloudflare.com/zh-cn ... rds/dns-ptr-record/
难怪,dns进行反向查找时,客户端ip是反的,我的实际ip是:10.0.235.72
到了上图,就变成了:
也难怪我没看出来,这个基本算是一个强力证据了,大概率是dns解析的问题,毕竟用了我的ip。
修改sshd配置
那就禁用这个机制吧,方式如下:
- vim /etc/ssh/sshd_config
- UseDNS no
复制代码
然后重启sshd
这样基本就ok了。重新试了下,再没有卡20s了,秒登录。
继续探索strace
找到问题原因后,strace我又继续研究了下。原来是少了个选项,-f:
- -f
- --follow-forks
- Trace child processes as they are created by currently traced processes as a result of the fork(2), vfork(2) and
- clone(2) system calls. Note that -p PID -f will attach all threads of process PID if it is multi-threaded, not only
- thread with thread_id = PID.
复制代码
这个选项是跟踪子进程的系统调用,因为,sshd收到一个客户端连接时,会fork一个新进程出来。前面都忘了加-f,所以导致没跟踪到。
换下命令:
- strace -p 93585 -s 1000 -t -e trace=network,file,desc,process -f
复制代码
这次可以跟踪了。
补充
在写这篇文章的时候,对一个地方产生了疑问。一般看日志的时候,对于systemd管理的service,我会看journalctl,也会看/var/log/messages,经常的情况是,在journalctl中的日志,在/var/log/messages中也能看到。
查了下两者的机制,参考:
https://serverfault.com/question ... er-than-var-log-mes
systemd会写日志到一些文件(journalctl就会读这些文件),然后,另一个后台进程rsyslogd,也会读这些日志,然后写到/var/log/messages这些文件中。
- [root@year-account-nginx2 log]# ps -ef|grep rsys
- root 1614 1 0 2022 ? 00:46:28 /usr/sbin/rsyslogd -n
复制代码
|