某日一位老师反映，机房的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执行命令。