一个客户项目中， 部署的环境是CentOS 7.9 ， SSH 版本是7.4 ，这也是系统默认的版本。同时，应客户要求，安装了G01和SafeDog 软件。 这是系统的基本情况。（懂的人应该就知道这是什么类型的客户了）

同时， 为了方便运维， 还在内网开通了SSH 端口， 通过深信服的系统进行连接。 这个SSH 端口是不对外网登录的，只能通过深信服的系统作为中转站，进行连接。

本来这一套系统运行是比较稳定的， 但是突然有一天，客户的IT部分负责人说，在一次巡检中，发现系统有安全漏洞！

安全漏洞截图

客户的通知就好比圣旨， 立马去检查， 发现漏洞的描述中，是针对CentOS7.6的版本，但是我们的版本已经升级到7.9了，似乎没有必要进行升级了。

OpenSSH（OpenBSD Secure Shell）是OpenBSD计划组所维护的一套用于安全访问远程计算机的连接工具。该工具是SSH协议的开源实现，支持对所有的传输进行加密，可有效阻止窃听、连接劫持以及其他网络级的攻击。OpenSSH 7.6之前的版本中的sftp-server.c文件的‘process_open’函数存在安全漏洞，该漏洞源于程序在只读模式下没有正确的阻止写入操作。攻击者可利用该漏洞创建长度为零的文件。

解决方案

目前厂商已发布升级补丁以修复漏洞，补丁获取链接：https://www.openssh.com/txt/release-7.6

但是， 客户的话也不能不听， 本着减少麻烦的宗旨，还是升级一下OpenSSH吧。但是这个决定， 让我后悔了整整三个星期！

一、升级

因为客户的安全报告是周四中午发出来的，客户要求周五解决，最迟需要在周五下午搞定，以免影响客户的安全汇报。

好吧， 客户的机器没有连接外网， yum 不能用， 在百度中搜索了半天，找到一个方案，也就是这个网址中的方案：https://cikeblog.com/update-openssh-8-1p1-html.html

“Centos7利用rpm升级OpenSSH到openssh-8.3p1版本”

这个似乎完全能满足我们的需求： 操作系统完全符合，不使用yum，还直接提供rpm包！ 简直是完美！

就在发布文章之际，我又翻看了一遍这个文章， 发现了中间这一段标红的字！ 我不确定是不是之前眼瞎，没看清楚，但是我没有照着这个来做！我恨！

所以，在此我建议， 凡是照着上面的教程来做的，一定要在看到上面这段红字的时候，执行如下命令：

# sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

当然这都是后话。在当时，已经是周四晚上了， 我打开远程ssh， 按照上面的教程，顺利地完成了openssh的升级， 执行ssh -V 命令，可以显示openssh 8.3了。

可是，当我重新启动ssh 服务，发现新建的ssh 连接不能连接！幸亏之前的ssh 没有关闭， 我开始恢复！然而， 即使时间的指针慢慢指向晚上11:30，各种ssh的办法都操作了一遍的时候， 情况没有丝毫的好转！

没错， 深信服的连接界面，就是这个样子：

二、没有ssh的悲惨世界

第二天，上午还要忙着新的项目的事情，等下午稍微有点时间的时候， 也是没有特别好的办法，上面文章中的办法都执行了，但是似乎并没有用。而且面临一个问题是，似乎客户的操作系统中，已经打开了SELinux！ 用各种关闭的命令，都不起作用。

悲催的是，时间很快到了客户下班的时间， 客户对满是绿色的安全报告很高兴，合上电脑就下班了， 但是，对于我们来说，仅有的ssh 连接也被关闭了！ 再也没办法远程操作客户机器了。

祸不单行，当你开始觉得自己很惨的时候，更悲惨的事情就会接二连三地到来。 因为增加了新的技术， 客户的项目连续出现了几个不大不小的问题， 修复之后，更新版本。幸好还预留了应用服务器的页面部署功能， 部署war 包还是可以的。 （对，技术就是这么落后，还在使用10年前的war包部署，微服务是没有的， Docker 也是没有的！）

但是， 可能是因为遗留的Druid 内存泄露问题， 在接连几次部署之后，在一个繁忙的周五之后， 应用服务器终于hang住了， 怎么操作也没有人响应了！芭比Q了！

没办法了， 只能等到周一去客户现场了！

可是，事情总是那么不凑巧，在某一个无聊的周六， 海淀的一位富有生活情调的女青年，成功成为2022年海淀1号核酸阳性患者！我的天！

三、修复问题

客户的问题还是要修复的，这次只能是我亲自去现场了！

这次去， 首先重启了系统！物理机重启，反正应用已经不行了。

重启之后发现，咦， SELinux 已经关闭了！难道之前的关闭SELinux，还需要重启一次才能起作用？ 还是说永久关闭SELinux的命令，需要下一次重启才能生效。

但是，经过验证，关闭SELinux，显然还是不能使SSH生效。

又找出了另外一篇文章，CENTOS7 OPENSSH升级8.3P1 不关闭SELINUXS使用SSH登录排错（https://www.freesion.com/article/99601327467/）

在这篇文章中，对我起作用的，是第二条：

查看/etc/pam.d目录，发现没有sshd，需要写入一个文件：

[root@localhost ~]#vi /etc/pam.d/sshd
#加入以下内容

#%PAM-1.0
auth       required     pam_sepermit.so
auth       substack     password-auth
auth       include      postlogin
# Used with polkit to reauthorize users in remote sessions
-auth      optional     pam_reauthorize.so prepare
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      password-auth
session    include      postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare

之前，客户系统的这个文件，至于前面四行，auth开头的只有三行。在更新了这个文件，重启ssh之后， ssh的登录终于成功了！

项目问题解决了，客户满意了， 老板脸上也有笑容了！

可是，对于广大程序员而言， 这仅仅就是一个无数平凡日子里的不大不小的浪花。短暂的高兴之后， 是一个又一个的bug和开发任务。

四、总结

对于CentOS 7.9 而言，如果你也遇到这种类似的SSH漏洞(CVE-2019-16905)， 那就不要迁就客户了， 直接怼回去吧：

这是CentOS7.6 的漏洞， 我们采用的是CentOS7.9，官方升级过了！

谨以此篇，记录在失去ssh之后的运维世界，那是一段痛苦的时光，同时也让我学到了很多平时不注意的知识！