記錄一次Linux遠程連接故障排查
問題描述:
接到用戶反饋,遠程連接linux服務器發生故障,具體情況是,當使用xshell遠程連接該服務器時,一直卡在連接界面上,直到超時,不能進入到服務器內部,截圖如下。

排查過程:
1.接到問題的第一反應是可能是ssh服務有問題,準備登錄到服務器內部,但是也出現了上面的情況,等待事件過長,就想著取消登錄,直接按下了ctrl+c,神奇的事情就發生了,居然進入了服務器內部,如下(一臉懵逼中···)

看到這個界面的時候,第一反應是用戶的配置文件丟了,但是查看了下,用戶家目錄中的文件完好,先不管這個問題了,先檢查ssh的配置文件和重啟了ssh服務之后再說,通過檢查ssh的配置文件,并沒有發現ssh配置文件被更改,重啟ssh服務也沒有問題。
2.接下來就是查看登錄日志文件,message日志文件和secure日志文件顯示信息如下,
查看message日志,顯示如下:

查看secure登錄日志,顯示如下:

通過上面的日志信息,可以看出,遠程服務器是接受了連接請求,但就是進入不了服務器,原因在哪里呢?
3.接下查看用戶的歷史命令,查看用戶最近修改過的配置文件
通過history查看用戶歷史命令記錄,未發現對認證文件的修改;
通過find /etc/ -type f -mtime -10命令查看用戶最近10天內更改過的/etc/目錄中的文件,也沒發現對認證文件更改的記錄,問題排查陷入僵局。
4.這個時候就只有百度查找看看是否有相同的故障處理記錄了,百度上的絕大部分是說/etc/passwd文件中用戶的shell被修改過,查看后,發現并沒有。
5.然后想到,在連接等待的過程中,通過ctrl+c能夠進入到服務器內部,那么就不應該是客戶端和服務端認證的問題,認證有問題是不可能進入到服務器中的,那么會不會是在認證之后發生的問題呢?比如加載用戶環境的時候發生了故障呢?
有了上面的想法后,就查看了跟用戶環境有關的配置文件,第一眼就看了全局環境配置文件/etc/profile,發現該文件中有一行source /etc/profile內容,立馬注釋掉該內容,重新登錄,登錄故障消除。
將source /etc/profile寫入/etc/profile為什么會導致登錄一直處于連接狀態呢?
當用戶登錄時,認證完成后,加載用戶環境的過程中,會使用到/etc/profile文件,當執行到source /etc/profile時,會再一次加載/etc/profile,不經意間此處形成了一個死循環,即無休止的加載/etc/profile文件,按下ctrl+c鍵能進入到服務器中,是由于人為的中斷了該文件的加載。
附用戶遠程連接系統后,環境變量加載過程圖(圖片來自網絡)

浙公網安備 33010602011771號