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这玩意儿,不出事则已,一出事就是连锁反应。别等被扫了才动手。