站長資訊網
最全最豐富的資訊網站

SSH服務突然連接不了案例總結

一臺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是應用層協議

SSH服務突然連接不了案例總結

吃飯回來后,發現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連接中,服務器首先提供其標識字符串,然后等待客戶端提供其標識字符串。 如果連接丟失,或者客戶端剛剛退出,就會出現日志中所看到的內容。

雖然懷疑是路由問題,但是個人手頭缺少網絡監控方面的詳實證據,但是也有一些佐證的證據:最近兩地網絡問題蠻多,前天還發現網絡掉包比較嚴重,網絡管理員找供應商反饋過,但是后面也不清楚什么情況。因為這方面的事情不歸我處理。

贊(0)
分享到: 更多 (0)
網站地圖   滬ICP備18035694號-2    滬公網安備31011702889846號
中文字幕精品亚洲无线码二区| 日韩欧毛片免费视频| 久久99视频精品| 97精品国产91久久久久久| 精品乱码一区内射人妻无码 | 精品国精品国产自在久国产应用男 | 久久精品国产清白在天天线| 久久亚洲精品无码播放| 国产精品 综合 第五页| 一本大道无码人妻精品专区| 国产精品1区2区3区在线播放| 久久久综合九色合综国产精品| 综合在线视频精品专区| 久久se精品一区精品二区国产| 国产成人高清精品免费观看| 午夜三级国产精品理论三级| 国产精品亚洲精品日韩动图| 日韩色视频一区二区三区亚洲| 2020精品自拍视频曝光| 亚洲精品国产电影午夜| 91大神精品在线观看| 91精品综合久久久久久五月天| 99re九精品视频在线视频| 国产精品免费在线播放| 精品国产高清久久久久久小说| 国产精品成人观看视频国产奇米 | A级精品国产片在线观看| 午夜麻豆国产精品无码| 国产精品女同一区二区| 亚洲韩国精品无码一区二区三区| 日韩高清在线不卡| 日韩高清在线观看永久| 久久久无码精品亚洲日韩蜜臀浪潮 | 久久综合日韩亚洲精品色| 亚洲日韩人妻第一页| 亚洲AV无码日韩AV无码导航| 日韩视频免费在线| 亚洲精品成人网久久久久久| 精品人妻V?出轨中文字幕| 国产午夜精品一区二区| 亚洲精品日韩专区silk|