1、故障现象
运维同事反馈一台生产服务器通过堡垒机无法访问SSH
服务器IP：192.168.31.127 （说明：文章中IP地址均非现场实际IP，这里为了复盘故障问题，使用模拟机器进行还原演示描述）
接到故障后，先通过VMware虚拟化平台控制台登录服务器，确认过服务器的root密码没有问题，控制台可以登录
(图片可点击放大查看)
但是通过堡垒机（192.168.31.254）就是无法访问
注释掉/etc/hosts.deny中SSH访问的黑名单(防止堡垒机绕过的SSH访问控制策略)
sshd: ALL :spawn echo `date` login attempt from %c to %s ,the host is %h .PID is %p >> /var/log/tcpwrapper.log
(图片可点击放大查看)
允许测试机器（192.168.31.230）访问SSH后，但是输入正确的密码就是无法正常登录
(图片可点击放大查看)
在控制台查看安全日志提示就是密码不对的报错
(图片可点击放大查看)
tail -f /var/log/secure
2、原因排查
pam_tally2
pam_tally2查看root SSH登录也没有锁住
排查了很久都没有找到原因 这时决定检查一下SSH的pam配置文件
神奇的发现/etc/pam.d/sshd文件空了
(图片可点击放大查看)
顿时知道为啥SSH输入正常的密码为啥也无法登录了
3、尝试恢复但又冒出新的问题
从正常的服务器SCP拷贝一个过来 但是发现scp root@192.168.31.230:/etc/pam.d/sshd /opt会报Permission deied错误
(图片可点击放大查看)
一度以为是192.168.31.230服务器有啥问题
但发现另外一台机器执行scp root@192.168.31.230:/etc/pam.d/sshd /opt，输入密码却是正常的
那说明192.168.31.230 SSHD服务正常
这时在故障服务器上尝试Debug看看
ssh -v root@192.168.31.230
在尝试密钥文件登录后就提示下面这句
(图片可点击放大查看)
debug1:No more authentication methods to try。
这时大致怀疑是不是本地的ssh_config有问题
cat /etc/ssh/ssh_config| grep -v ^# | grep -v ^$
看到这个PasswordAuthentication no
瞬间明白了
(图片可点击放大查看)
修改为#PasswordAuthentication yes
(图片可点击放大查看)
4、问题解决
scp root@192.168.31.230:/etc/pam.d/sshd /opt
cp /opt/sshd /etc/pam.d/sshd
(图片可点击放大查看)
这时再用堡垒机登录就正常登录了
(图片可点击放大查看)
5、简单加固措施和总结
- 1、加固
排查为啥这两个文件为啥被修改了，两个问题同时出现也是非常"吊诡"
查看堡垒机审计录像未找到相关的运维动作。
那就先做些加固吧
1、chattr +i /etc/pam.d/sshd
2、chattr +i /etc/ssh/ssh_config
- 2、总结 阿里云上总结的比较详细，供参考
https://help.aliyun.com/document_detail/41470.html