Rocky Linux 9修复CVE-2024-6387 SSH漏洞：原理、步骤与加固指南

1. 项目概述与漏洞背景最近在运维圈子里CVE-2024-6387 这个漏洞编号被讨论得沸沸扬扬。它有个更形象的名字叫“regreSSHion”直译过来就是“SSH 回归”指的是一个在 OpenSSH 服务器中沉寂了近二十年、最近又被重新引入的严重安全漏洞。简单来说它能让攻击者在特定条件下远程获取到服务器的最高权限root。对于任何使用 Rocky Linux 9 或其他 RedHat 系发行版作为生产环境的团队来说这都不是一个可以忽视的“小补丁”。我管理的几十台服务器里大部分都跑着 Rocky Linux 9所以第一时间就着手处理了。这篇文章我就把从漏洞原理分析、影响范围判断到具体的修复步骤、修复后的验证以及一些在复杂生产环境中可能遇到的“坑”和应对策略完整地梳理一遍。无论你是刚接触 Linux 运维的新手还是经验丰富的系统管理员都能在这找到可直接操作的方案和背后的思考逻辑。这个漏洞的核心在于 OpenSSH 服务器sshd处理信号的一个竞态条件race condition。在特定版本的 glibc 库和 32 位 Linux 系统上攻击者可以通过维持大量并发的、长时间存活的 SSH 连接最终触发这个条件导致 sshd 进程崩溃并可能执行任意代码。虽然目前公开的利用证明主要针对 32 位系统并且平均需要 6-8 小时才能成功但安全界普遍认为在 64 位系统上实现利用只是时间问题而且攻击手法很可能会被优化。因此对于所有运行受影响 OpenSSH 版本8.5p1 到 9.7p1的系统及时修复是必须的。对于 Rocky Linux 9 用户好消息是 Rocky 社区和上游 RedHat 已经迅速响应提供了修复后的安全更新包。2. 漏洞影响分析与环境确认在动手修复之前盲目操作是大忌。我们必须先搞清楚两个问题我的系统到底受不受影响如果受影响当前处于什么状态这一步的排查能避免我们误操作健康的系统或者漏掉真正有风险的机器。2.1 确认操作系统与 OpenSSH 版本首先我们需要登录到目标 Rocky Linux 9 服务器。通常通过现有的、未受影响的 SSH 连接或者控制台进行操作。第一步确认系统版本。虽然我们知道是 Rocky Linux 9但最好还是用命令核实一下避免误操作到其他版本的系统比如 Rocky Linux 8 不受此漏洞影响。cat /etc/redhat-release或者hostnamectl | grep -i operating system对于 Rocky Linux 9你会看到类似Rocky Linux release 9.x (Blue Onyx)的输出。接下来检查当前安装的 OpenSSH 服务器版本这是判断是否受影响的关键。rpm -qa | grep openssh-server或者更精确地查询 openssh 主包rpm -q openssh关键版本比对如果输出的版本号在openssh-8.5p1到openssh-9.7p1之间包含两端那么你的系统就存在潜在风险需要修复。在 Rocky Linux 9 的默认仓库中通常安装的是openssh-8.7p1系列版本。例如你可能会看到openssh-8.7p1-38.el9.x86_64这样的输出。这里的38.el9是发行版打包版本号我们需要关注的是主版本8.7p1它正好落在受影响范围内。注意仅仅检查sshd -V命令的输出有时不够准确因为它显示的是 sshd 二进制文件的版本而 RPM 查询才是判断系统已安装软件包版本的权威方法。在修复前后我们都应该以 RPM 查询结果为准。2.2 理解漏洞利用条件与风险评估知道了版本号在受影响范围我们还需要评估实际风险等级这有助于安排修复的优先级。根据公开信息CVE-2024-6387 的利用有几个关键限制架构依赖已被证实的利用发生在32位i686/x86的 Linux 系统上。虽然理论上 64 位x86_64系统也可能存在风险但截至目前没有公开的、稳定的利用方式。不过安全原则是“假定有风险”所以 64 位系统同样需要修复。环境要求需要系统启用地址空间布局随机化ASLR。这是现代 Linux 发行版的默认安全特性Rocky Linux 9 默认就是开启的。你可以通过cat /proc/sys/kernel/randomize_va_space来确认输出2表示完全启用。攻击成本在实验室环境下成功利用平均需要维持6-8 小时的持续连接。这意味着它不是一个可以瞬间得手的“秒杀”漏洞攻击者需要长时间、高频率地撞击服务器通常会被IDS/IPS或异常连接监控发现。服务状态只有运行中的sshd服务受影响。如果你的服务器虽然安装了 openssh-server 但并未启用systemctl is-active sshd返回inactive那么风险极低但你仍然应该在启用前更新。基于以上分析我们可以制定修复策略面向公网、业务重要的 64 位服务器高优先级。虽然利用难度大但一旦被攻破后果严重。内网服务器、开发测试环境中优先级。可以安排在业务低峰期进行。纯 32 位架构的系统最高优先级。需要立即安排修复窗口。未运行 sshd 的服务低优先级但应在下次启用前完成更新。2.3 修复前的必要准备工作“磨刀不误砍柴工”在生产环境上动关键服务准备工作必须做足。以下是修复前必须完成的检查清单备份现有 SSH 配置这是最重要的步骤防止更新过程中配置被意外重置或覆盖。sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date %Y%m%d)同时也建议备份一下.ssh/authorized_keys文件对于root用户是/root/.ssh/authorized_keys对于普通用户在各自家目录下。确保你有替代的访问方式在更新和重启 sshd 服务的过程中如果配置有误或服务启动失败你可能会失去 SSH 连接。对于物理服务器或云主机请确保你拥有物理控制台访问如 iDRAC, iLO, IPMI。云服务商提供的 VNC 或串口控制台如 AWS EC2 的 Instance Connect 阿里云/腾讯云的 VNC。通过跳板机Bastion Host或其他管理网络的访问途径。绝对不要在只有一条 SSH 通道的情况下贸然重启关键生产服务器的 sshd 服务。检查系统更新源确保你的 Rocky Linux 9 系统能够正常访问官方更新仓库。执行sudo dnf makecache测试一下。如果系统在内网需要配置好内部镜像源。通知相关方如果这是台业务服务器务必提前通知业务负责人或团队成员告知维护窗口和可能出现的短暂连接中断。3. 修复方案详解与分步操作对于 Rocky Linux 9 用户来说修复这个漏洞非常直接因为修复包已经进入了稳定仓库。我们不需要手动编译源码也不需要添加额外的第三方仓库在漏洞刚披露的短暂窗口期可能需要通过security-common仓库获取但现在已整合进主仓库。下面是完整的、一步到位的修复流程。3.1 标准修复流程通过默认仓库这是最推荐、最简洁的修复方法。Rocky Linux 的更新机制会确保你获取到经过充分测试的稳定版本。更新系统仓库元数据首先让 dnf 获取最新的软件包列表信息。sudo dnf makecache检查可用的 openssh 更新在正式更新前可以先查看一下有哪些 openssh 相关的包可以升级。sudo dnf check-update openssh\*这个命令会列出所有可更新的 openssh 相关包openssh, openssh-server, openssh-clients 等但不会执行任何更改。你应该能看到版本号至少升级到了8.7p1-38.el9_4.1或更高。执行更新操作使用dnf upgrade命令来升级 openssh 及其相关组件。sudo dnf upgrade openssh openssh-server openssh-clients你也可以使用通配符来升级所有相关包这更省事sudo dnf upgrade openssh\*执行命令后dnf 会解析依赖关系并显示将要升级的软件包列表和需要下载的大小。请仔细核对版本号确认是升级到修复版本如8.7p1-38.el9_4.1。输入y并回车确认。观察更新过程更新过程中dnf 会自动处理旧包的卸载和新包的安装。关键点来了在安装openssh-server新包时安装脚本%postscriptlet通常会尝试重启 sshd 服务。你会看到类似Running scriptlet: openssh-server-...的输出。这意味着在更新完成的瞬间你的当前 SSH 会话可能会因为服务重启而短暂卡顿或断开。但别担心因为 SSH 客户端具有连接保持和重连机制绝大多数情况下你的当前连接会恢复。不过正如之前强调的有备用访问渠道至关重要。验证安装版本更新完成后立即验证安装的版本。rpm -q openssh openssh-server openssh-clients预期的输出应该是openssh-8.7p1-38.el9_4.1.x86_64 openssh-server-8.7p1-38.el9_4.1.x86_64 openssh-clients-8.7p1-38.el9_4.1.x86_64只要版本号中的发布版本el9_4.1等于或高于此版本即说明漏洞已修复。确认服务状态最后检查 sshd 服务是否正常运行。sudo systemctl status sshd你应该看到Active: active (running)的状态并且启动时间应该是刚刚更新之后。3.2 修复方案原理解析为什么直接dnf upgrade就够了很多朋友可能会问网上有些教程提到要添加rocky-release-security仓库或者启用security-common仓库为什么这里不需要这里涉及到 Linux 发行版安全更新的发布流程。安全更新的分级发布当一个严重漏洞如 CVE-2024-6387被披露后上游RedHat会迅速制作修复补丁。最初这个补丁可能会先放在一个专门的安全测试仓库如security-common中供早期采用者和测试者使用。这时如果你非常紧急可以按照早期教程手动启用这个仓库来获取更新。进入稳定仓库经过短暂的测试和验证确认修复包与系统其他组件兼容良好后这个安全更新就会被推送到默认的稳定仓库如baseos和appstream。对于 Rocky Linux 9在漏洞披露后不久修复包openssh-8.7p1-38.el9_4.1就已经进入了稳定仓库。dnf upgrade的工作机制dnf upgrade命令默认会检查所有已启用的仓库主要是baseos和appstream并安装其中最新的版本。因此当修复包进入稳定仓库后最简单的sudo dnf upgrade openssh\*就能完成任务无需任何额外配置。这也是最安全、最推荐的方式因为它确保你获取的是经过完整质量保证的版本。所以如果你现在距离漏洞披露已有一段时间按照本文操作直接更新即可。那些需要添加特殊仓库的步骤是漏洞刚爆发时的“应急方案”现在可以看作是过时了。3.3 针对特殊环境的修复调整虽然标准流程适用于99%的场景但总有一些特殊情况需要考虑。场景一系统无法连接外网离线环境对于内网隔离的服务器你需要搭建一个本地镜像仓库或者手动下载 RPM 包进行离线安装。在有网络的环境中下载 RPM 包# 在一个能联网的、同版本的 Rocky Linux 9 系统上 mkdir openssh_update cd openssh_update sudo dnf download openssh openssh-server openssh-clients --resolve这会将所有需要的包下载到当前目录。你需要将这些.rpm文件拷贝到离线服务器。在离线服务器上安装# 在离线服务器上进入存放 RPM 包的目录 sudo rpm -Uvh openssh-*.rpm-Uvh参数代表升级、显示详细信息、显示进度。注意离线安装可能需要手动解决依赖关系dnf download --resolve已经帮你下载了依赖包所以一起安装即可。场景二使用了自定义编译的 OpenSSH极少数情况下有的管理员可能卸载了发行版的 openssh自己编译安装了新版。这时你需要评估自定义版本的版本号是否在受影响范围8.5p1 - 9.7p1。如果受影响建议优先考虑回退到发行版提供的安全包因为自行维护安全补丁风险很高。可以备份你的自定义配置和二进制文件然后使用sudo dnf install openssh openssh-server openssh-clients重新安装发行版包。如果必须坚持自定义版本则需要关注 OpenSSH 上游的补丁到 9.8p1 版本已修复并自行编译更新。这超出了本文范围且不推荐在生产环境使用。场景三大规模服务器批量修复如果你管理着成百上千台 Rocky Linux 9 服务器手动登录每一台操作是不现实的。这时需要借助自动化工具Ansible编写一个简单的 playbook。- name: Patch CVE-2024-6387 on Rocky Linux 9 hosts: all become: yes tasks: - name: Upgrade OpenSSH packages dnf: name: {{ item }} state: latest loop: - openssh - openssh-server - openssh-clients notify: restart sshd handlers: - name: restart sshd systemd: name: sshd state: restarted enabled: yesSaltStack / Puppet / Chef使用对应的模块或 recipe 来确保openssh包为最新版本。脚本化批量执行通过像pssh、clustershell这样的工具将sudo dnf upgrade openssh\* -y命令分发到所有主机。无论用哪种方式务必先在小范围测试环境中验证确认更新不会导致业务中断或兼容性问题后再分批推送到生产环境。4. 修复后验证与安全加固建议更新完软件包服务也重启了这就算完成了吗远远不够。作为一个负责任的运维我们必须进行闭环验证并思考如何借此机会提升整体的 SSH 安全水位。4.1 多维度验证修复是否生效仅仅版本号对了还不够我们需要从多个角度确认漏洞确实被堵上了。版本号验证再次确认这是最基本的。rpm -qa | grep ^openssh服务进程验证检查正在运行的sshd进程其对应的二进制文件版本是否已更新。# 获取 sshd 主进程的 PID pidof sshd # 查看该 PID 对应可执行文件的路径和版本信息 sudo strings /proc/$(pidof sshd)/exe | grep -i openssh或者更直接地使用sshd自带的版本查询注意这可能显示的是编译时的版本但也能佐证sudo sshd -V 21 | head -1漏洞扫描工具验证可选但推荐如果公司有 Nessus, OpenVAS, Qualys 等漏洞扫描器可以在修复后对该服务器发起一次新的扫描确认 CVE-2024-6387 的风险等级已从“高危”降为“已修复”或“低风险”。这是向安全团队和审计部门证明工作已完成的强有力证据。功能性测试更新后务必测试 SSH 连接是否一切正常。从不同的客户端如 Linux 的 ssh 命令、Windows 的 PuTTY、VS Code Remote-SSH 等进行连接测试。测试各种认证方式密码认证、公钥认证。测试 SSH 隧道、端口转发等高级功能如果业务用到的话。检查相关的自动化脚本或 CI/CD 流水线确保它们使用的 SSH 连接仍然工作。4.2 借此机会进行 SSH 安全加固修复一个漏洞是“治标”建立更稳固的安全配置才是“治本”。趁着这次更新强烈建议你审查并加固服务器的 SSH 配置。打开 SSH 服务器配置文件/etc/ssh/sshd_config考虑以下加固选项修改前请备份sudo vi /etc/ssh/sshd_config关键加固项禁用密码登录强制使用公钥认证这是防止暴力破解最有效的一招。PasswordAuthentication no PubkeyAuthentication yes注意在关闭密码认证前请确保所有需要登录的用户都已将其公钥添加到服务器的~/.ssh/authorized_keys文件中并且你自己有可用的私钥进行连接测试。否则会被锁在服务器外面禁止 root 用户直接登录即使使用密钥也不建议直接用 root 登录。先以普通用户登录再su或sudo。PermitRootLogin no限制监听接口如果服务器有多个网卡但 SSH 只服务于内网可以将其绑定到内网 IP减少暴露面。ListenAddress 192.168.1.100 # 替换为你的内网IP修改默认端口将端口从 22 改为一个非标准端口可以显著减少自动化扫描和攻击脚本的滋扰。Port 2222 # 示例端口请使用1024-65535之间的端口重要提示修改端口后必须在防火墙firewalld/iptables中开放新端口并记得在连接时指定端口ssh -p 2222 userhost。使用更强的密钥交换算法和加密算法禁用已知不安全的旧算法。KexAlgorithms curve25519-sha256,curve25519-sha256libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305openssh.com,aes256-gcmopenssh.com,aes128-gcmopenssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etmopenssh.com,hmac-sha2-256-etmopenssh.com,umac-128-etmopenssh.com使用 Fail2ban 阻止暴力破解Fail2ban 可以监控 SSH 日志短时间内多次失败尝试后自动将攻击者 IP 加入防火墙黑名单。sudo dnf install -y fail2ban sudo systemctl enable --now fail2ban配置通常位于/etc/fail2ban/jail.local你可以启用[sshd]部分。每次修改sshd_config后都需要重载配置或重启服务并务必在另一个终端窗口保持一个有效的 SSH 连接以防配置错误导致无法登录。sudo systemctl reload sshd # 或者 sudo systemctl restart sshd sudo systemctl status sshd # 检查服务状态4.3 建立长期的安全更新机制一次修复不能一劳永逸。我们应该建立机制确保系统能持续、及时地获取安全更新。启用自动安全更新谨慎评估对于开发测试环境或不那么关键的系统可以考虑启用自动安全更新。sudo dnf install -y dnf-automatic sudo systemctl enable --now dnf-automatic.timer生产环境警告对于核心生产系统不建议完全自动更新。安全更新虽然重要但仍有极低概率引入兼容性问题。生产环境更佳实践是自动下载但不安装然后由运维人员在经过测试的维护窗口内手动安装。定期手动更新与检查建立例行工作比如每周或每两周手动检查并应用安全更新。sudo dnf check-update --security # 仅检查安全更新 sudo dnf update --security # 仅安装安全更新订阅安全通告关注 Rocky Linux 或上游 RedHat 的安全邮件列表、博客或 RSS及时获取漏洞情报。5. 常见问题排查与实操心得在实际操作中尤其是在复杂或老旧的生产环境里你可能会遇到一些预料之外的问题。下面是我和同事们踩过的一些“坑”以及对应的解决方案。5.1 更新失败依赖包冲突或损坏问题现象执行sudo dnf upgrade openssh\*时报错提示依赖关系不满足、文件冲突或者某个包损坏。排查与解决清理 DNF 缓存并重建有时元数据损坏会导致问题。sudo dnf clean all sudo dnf makecache检查并修复 RPM 数据库sudo rpm --rebuilddb使用dnf的疑难解答模式dnf提供了更详细的错误信息。sudo dnf upgrade openssh\* -v --nobest-v显示详细信息--nobest有时能绕过一些苛刻的版本依赖检查。手动强制安装最后手段如果确认是新包本身的问题可以尝试从官方镜像站手动下载对应版本的 RPM 包强制安装。但这种方法可能破坏依赖关系需极其谨慎。# 假设包已下载到本地 sudo rpm -Uvh --force openssh-8.7p1-38.el9_4.1.x86_64.rpm openssh-server-... openssh-clients-...5.2 更新后 SSH 服务无法启动问题现象更新完成但sudo systemctl status sshd显示服务失败日志sudo journalctl -u sshd -xe中有错误信息。常见原因与解决sshd_config语法错误这是最常见的原因。可能在更新前后不小心修改了配置文件或者更新包自带的默认配置与你的自定义配置冲突。解决方案使用sshd自带的语法检查工具。sudo sshd -t这个命令会检查/etc/ssh/sshd_config的语法并指出错误所在行。根据提示修复即可。如果之前有备份可以快速回滚。SELinux 上下文问题在极少数情况下更新后 SSH 相关的二进制文件或库文件的 SELinux 安全上下文可能不正确。解决方案恢复默认上下文。sudo restorecon -Rv /etc/ssh /usr/sbin/sshd /usr/libexec/openssh端口被占用如果你修改了 SSH 端口而新端口已被其他程序占用。解决方案检查端口占用。sudo ss -tlnp | grep :2222 # 替换为你的端口号停止占用端口的进程或为 SSH 选择另一个端口。5.3 更新后连接速度变慢或出现超时问题现象更新后 SSH 连接建立变慢或者偶尔超时。排查思路检查 DNS 反向解析OpenSSH 默认会尝试对客户端 IP 进行反向 DNS 解析。如果 DNS 服务器响应慢或不可达就会导致连接延迟。解决方案在sshd_config中禁用反向 DNS 解析。UseDNS no修改后重启 sshd 服务。检查 GSSAPI 认证如果客户端或服务器配置了 GSSAPI (Kerberos) 认证且配置不当也会在认证阶段引入延迟。解决方案如果不需要可以禁用它。GSSAPIAuthentication no防火墙规则确认更新操作没有误删或影响防火墙规则。特别是如果你修改了 SSH 端口必须确保新端口在防火墙firewalld/iptables中是放行的。sudo firewall-cmd --list-all # 查看 firewalld 当前规则 sudo firewall-cmd --add-port2222/tcp --permanent # 添加新端口如果修改了 sudo firewall-cmd --reload5.4 关于“自动重启服务”的深度理解在更新openssh-server包时RPM 的%post脚本会尝试重启服务。但这个“重启”行为可能因系统配置而异如果sshd服务正在运行脚本会执行systemctl try-restart sshd或类似命令这通常会成功导致你的会话短暂中断后恢复。如果sshd服务被systemctl mask屏蔽了或者服务处于非活跃状态RPM 脚本可能无法重启它。更新后你需要手动启动。最佳实践无论脚本是否成功在更新完成后手动检查并确认一次服务状态总是一个好习惯。sudo systemctl is-active sshd # 应为 active sudo systemctl is-enabled sshd # 应为 enabled (开机自启)5.5 个人实操心得与建议变更窗口选择对于在线业务务必选择流量最低的维护窗口例如深夜。即使更新很快也要预留出回滚和故障排查的时间。“先测试后生产”铁律永远先在非生产环境开发、测试、预发布验证更新流程和兼容性。可以用虚拟机克隆一份生产环境来做测试。文档化操作步骤像本文这样的操作指南不仅可以帮助他人更是你下次执行类似操作的检查清单。将验证命令如rpm -q openssh也写入你的运维手册或自动化脚本中。监控与告警更新后除了手动测试还应该观察一段时间内的服务器监控指标CPU、内存、网络连接数和业务日志确保没有异常。可以设置一个针对sshd服务状态的简单告警。保持敬畏之心安全更新是运维的日常工作但每一次操作都涉及风险。即使是一个简单的dnf update也可能因为仓库镜像不同步、网络问题或罕见的包冲突而出错。耐心、细致和充分的备份是运维人员最好的朋友。通过以上步骤你不仅能够安全、彻底地修复 CVE-2024-6387 漏洞更能将一次被动的漏洞响应转化为一次主动的安全配置审计和加固机会从而全面提升服务器的安全基线。