某日一位老師反映，機房的6號節點無法登錄了。一開始以為是為節點防火牆配置IP白名單時忘記了加進去，但隨后發現此節點並未進行白名單配置，密碼也一直未有變更，於是在自己的電腦上連接，發現終端里很快顯示出了Last login信息，說明這時應該已經成功與節點進行了連接，但隨后就報出Connection closed，連接被關閉了。
都在一棟樓里，不大可能是網絡問題，於是去機房里排查問題。將KVM控制平台連接到節點上后，發現屏幕上輸出了一些類似設備調試中的報錯信息，且已經完全卡死，不接受鍵盤的中斷信號，於是只好長按強制關機，但再次開機后怪事發生了。
輸入用戶名root和密碼后，Shell給出了這樣的提示
（failed login是之前記錯密碼導致的）
顯然不是密碼問題，因為Last login信息已經顯示就表明密碼無誤，但root用戶在本地登錄都會被拒絕，這個就有點嚇人了，第一時間想到是不是遭遇黑客，趕緊到網上搜索相關問題，但回答大多都是針對SSH登錄的情況，未見到本地登錄也會被拒絕。有些文章提到可用普通用戶登錄，但此節點並未設置其他用戶，無法嘗試。
想要進行修復工作，首先必須想辦法進入系統，於是嘗試了一下單用戶模式（關於單用戶模式可參見 https://blog.51cto.com/hqq0000/2177280），發現可以進入！這下先松了一口氣，至少實在沒轍了可以把數據導出然后重裝系統，要不然就得把整個集群斷電拆硬盤了。
在單用戶模式下，先修改了下密碼，發現沒用；然后又懷疑是不是bash出了問題，因為permission denied常見於執行某些沒有執行權限的文件時，如果/bin/bash被惡意更改了權限，貌似是可能報這樣錯誤的，但用ls -l看了下，也不是bash的事。
想到登錄失敗，日志中會有記錄，於是查看/var/log/secure，發現末尾有如下一段記錄
似乎登錄失敗的原因就出在這個pam上。PAM是Linux的一個動態驗證模塊，可能是它阻止了我們的登錄行為。注意到最后幾行，有提到nofile，這不是Linux最大打開文件數那個限制參數嗎？於是進行調整（參見https://www.iteye.com/blog/jameswxx-2096461 總結的很不錯），但仍未能解決問題。
繼續分析日志，發現這樣一行
確實，6號節點的所有用戶，uid都小於1000，於是根據網上的解決方案（https://help.aliyun.com/knowledge_detail/41491.html?spm=a2c6h.13066369.0.0.2edd1479unyVgh），對/etc/pam.d下的文件進行修改，把system-auth中的相關語句注釋掉了
但重啟后發現還是沒用！原來system-auth 會在重啟后自動恢復配置，手工更改是無效的。
那么換個思路，既然禁止uid<1000的用戶登錄，我使用>1000的不就可以了？繼續在單用戶模式下，adduser創建了一個普通用戶，passwd設置密碼，並加入到root組里使其可以用sudo，重啟，登錄......
......還是不行......
難道就沒有辦法繞過pam了嗎？突然想到ssh_config里好像有一個參數與PAM有關，叫use_PAM，馬上打開一看，果然，被設置為了yes，趕緊改回no，然后回樓上ssh連接。
普通用戶，root均成功！這回可算是解決了。
總結
經過一番排查，最終定位是PAM惹的禍，如果自己對PAM熟悉，應該會更快地定位問題。目前只是恢復了root用戶的遠程登錄，對於root為什么在本地也會被拒絕，還未能找到答案。
但另一方面來講，Linux設置PAM也必然有自己的考量，運行root遠程登錄，本身就存在一定安全風險，管理員還是應該只允許普通用戶遠程登錄，而后使用su切換或sudo執行命令。