OpenSSH爆出高危漏洞那天，洞何我正蹲在机房调交换机。修复手机弹窗跳出来，洞何扫了一眼——CVE-2024-6387，修复远程代码执行，洞何影响8.5p1到9.7p1。修复手边三台跳板机全中。洞何当时后背一凉，修复这玩意儿要是洞何被扫到，等于把服务器钥匙插门上还贴了张纸条。修复

修复这事，洞何说穿了就三条路：升级、修复打补丁、洞何改配置。修复但具体怎么走，洞何得看你手里是什么系统、什么版本、能不能停机。

先搞清楚你中的是哪一招

OpenSSH的漏洞分两类。一类是协议实现层面的，比如那个臭名昭著的CVE-2024-6387，攻击者能在默认配置下直接拿shell。另一类是配置不当引发的，比如允许root直接登录、用了弱密钥交换算法。很多人一看到“漏洞”俩字就慌，其实先跑一条命令比什么都管用：

ssh -V

输出里那串版本号，就是你的命门。低于9.8p1的，CVE-2024-6387基本跑不掉。但别急着动手，先确认你的发行版有没有 backport 补丁。Red Hat和Ubuntu经常把安全修复塞进旧版本号里，看着是8.x，其实已经补过了。查这个得看发行版的安全公告，别光盯着OpenSSH官方版本。

升级是最干脆的，但坑最多

源码编译升级听着简单，实际上一堆依赖。zlib、OpenSSL、pam，少一个都编不过。我见过有人直接./configure && make install，结果把系统自带的ssh搞崩了，连不上机器只能去机房插显示器。正确做法是先备份：

cp /usr/sbin/sshd /usr/sbin/sshd.bak cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

然后编译时指定--prefix=/usr，别用默认的/usr/local，否则systemd的服务文件路径全乱。装完别急着重启，先/usr/sbin/sshd -t测试配置。没问题了再systemctl restart sshd。这时候千万别关当前会话，另开一个终端连上去试试。我吃过亏，重启完sshd起不来，当前会话一断就彻底失联。

包管理器升级更稳，但得看源

Debian/Ubuntu用户直接apt update && apt install --only-upgrade openssh-server。CentOS/RHEL用yum update openssh-server。前提是你的源里已经有修复版本。国内有些镜像站同步慢，等半天还是旧包。可以临时换成官方源或者阿里云、腾讯云的镜像。升级完systemctl status sshd看一眼，确认服务正常。

有个细节：Ubuntu 20.04默认的OpenSSH是8.2p1，官方早就停止维护了。这种情况要么升级系统，要么自己编译。别指望apt upgrade能解决，源里根本没有新版本。

实在升不了，就改配置兜底

有些老系统动不了，比如跑着关键业务、内核版本太旧、编译环境缺失。这时候只能靠sshd_config硬扛。针对CVE-2024-6387，核心思路是缩短LoginGraceTime，让攻击窗口变小：

LoginGraceTime 0

但设成0意味着连接后如果不认证就永远挂着，反而容易被DoS。折中方案是设成10秒或更短。另外把MaxStartups调低，限制并发未认证连接数：

MaxStartups 10:30:10

再狠一点，直接限制来源IP。/etc/hosts.allow里只放信任的网段，其他全拒。这招对CVE-2024-6387有效，因为攻击包根本到不了sshd。但缺点是运维麻烦，每次加机器都得改配置。

修完别忘了验证

重启完sshd，用nmap -p 22 --script ssh2-enum-algos <目标IP>扫一下，看密钥交换算法列表里还有没有diffie-hellman-group1-sha1这种老古董。有的话在配置里显式禁用：

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256

再跑一遍ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -v user@host，看协商过程有没有报错。最后用漏洞扫描器过一遍，确认CVE-2024-6387不再命中。

我自己的习惯是修完写个记录：什么时间、哪台机器、从哪个版本升到哪个版本、遇到什么问题、怎么解决的。下次再出漏洞，翻记录比翻文档快得多。OpenSSH这玩意儿，不出事则已，一出事就是连锁反应。别等被扫了才动手。