(點選上方公眾號,可快速關註)
來源:瀟湘隱者 ,
www.cnblogs.com/kerrycode/p/9770032.html
一臺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已經可以正常登入伺服器,檢查發現這個行程已經運行了二百多天了,那麼也就是說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連線不了的排錯,其實有不少系統的排查方法,下麵這三篇部落格非常精彩,此處就不班門弄斧,有興趣的可以直接看看這些文章。
-
https://note.t4x.org/other/didnot-receive-identification-string-from/
-
https://www.centos.bz/2017/08/ssh-connect-failed-solve-experience/
-
https://scottlinux.com/2012/03/07/troubleshooting-ssh-server-logs-and-error-messages/
【關於投稿】
如果大家有原創好文投稿,請直接給公號傳送留言。
① 留言格式:
【投稿】+《 文章標題》+ 文章連結
② 示例:
【投稿】《不要自稱是程式員,我十多年的 IT 職場總結》:http://blog.jobbole.com/94148/
③ 最後請附上您的個人簡介哈~
看完本文有收穫?請轉發分享給更多人
關註「ImportNew」,提升Java技能