一台Oracle数据库处事器（Linux版本为Oracle Linux Server release 5.7）本日中午溘然呈现短暂的ssh毗连不上的环境，ssh毗连不上的时候，ping处事器正常，利用psping检测端口22也是正常（只返回5个包，没有一连ping），昆山软件公司，利用SQL Developer可以登录数据库举办任何操纵，别的，通过DPA东西发明该处事器的CPU等资源耗损很低（发明数据库处事都正常后，就出去用饭了），返来时，同事反馈ssh已经正常，错过诊断的大好机缘，期间别的一个同事也做了一些查抄：

检测发明ping正常，昆山软件开发，可是psping检测8088端口发明网络时延很长，甚至呈现超时。他做了一个截图比拟，如下所示

ping是一个网络层的协议，只是表白网络在3层是通的；tomcat是应用层协议

劳务调派信息打点系统 清楚什么环境" class="aligncenter size-full wp-image-30266" title="73542-20180901000857559-500188632" src="/uploads/allimg/c181023/154023TU33320-12006.png" />

用饭返来后，发明ssh已经可以正常登录处事器，查抄发明这个历程已经运行了二百多天了，那么也就是说sshd处事没有死掉，sshd处事也没有重启过。

利用ps -ef | grep sshd 找到sshd的历程，执行下面呼吁 

[root@mylnx01 ~]# ps -eo pid,lstart,etime | grep 3423 
3423 Sun Feb 18 13:56:11 2018 234-09:01:48

查抄日志信息，发明内里有几条 Did not receive identification string from xxx的信息（部门信息做了脱敏处理惩罚）。 

[root@mylnx01 log]# tail -100 /var/log/secure
Oct  8 14:50:48 mylnx01 sshd[4341]: pam_unix(sshd:session): session opened for user oracle by (uid=0)
Oct  8 14:50:49 mylnx01 sshd[4341]: pam_unix(sshd:session): session closed for user oracle
Oct 10 12:26:41 mylnx01 sshd[742]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[743]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[790]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[789]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[745]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[744]: Did not receive identification string from 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[1007]: Connection closed by 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[1006]: Connection closed by 192.168.xxx.xxx
Oct 10 12:26:41 mylnx01 sshd[746]: Did not receive identification string from 192.168.xxx.xxx

搜索了一下这个错误的相关资料，一般呈现错误是因为：

This one below means ssh server waited and did not receive what it needed in a timely fashion. This is typically due to connectivity issues. In an ssh connection, the server first provides its identification string, then waits for the client to then provide its identification string. If there is a loss in connection, or the client just bails, this is what you will see in the logs.
If someone uses telnet or netcat to fetch your ssh banner, or other various scans, the logs on the server side will show this as well.

这个错误信息意味着ssh处事由于没有实时收到它所需要的对象，而呈现期待现象。 凡是是由于毗连问题造成。 在ssh毗连中，处事器首先提供其标识字符串，然后期待客户端提供其标识字符串。 假如毗连丢失，可能客户端方才退出，就会呈现日志中所看到的内容。

固然猜疑是路由问题，可是小我私家手头缺少网络监控方面的详实证据，昆山软件开发，可是也有一些佐证的证据：最近两地网络问题蛮多，前天还发明网络偷换较量严重，网络打点员找供给商反馈过，可是后头也不清楚什么环境。因为这方面的工作不归我处理惩罚。

对付ssh毗连不了的排错，其实有不少系统的排查要领，下面这三篇博客很是出色，此处就不班门弄斧，有乐趣的可以直接看看这些文章。