记一次非常"吊诡"的生产服务器SSH无法访问故障处理过程

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

原文地址：https://cloud.tencent.com/developer/article/2187562