Rocky Linux 9 OpenSSH漏洞CVE-2024-6387修复实战与安全加固指南

1. 项目概述：一次紧急的OpenSSH漏洞修复实战

最近在运维圈子里，CVE-2024-6387这个漏洞编号被讨论得沸沸扬扬。作为一个长期在生产环境部署Rocky Linux的运维，我第一时间就绷紧了神经。这个漏洞影响的是我们几乎每天都在用的OpenSSH服务，一个处理远程登录的核心组件。简单来说，它涉及到一个潜在的远程代码执行风险，虽然利用条件相对苛刻，但在安全领域，任何潜在的风险敞口都必须被立即关闭。对于像我们这样将Rocky Linux作为CentOS替代品，承载着关键业务系统的团队来说，这可不是一个可以“等等再看”的更新。

你可能也注意到了，网上关于“Rocky Linux国内有人用吗”、“Rocky Linux 9下载”的搜索热度不低，这说明越来越多的团队，特别是那些从CentOS迁移过来的，正在拥抱这个由社区驱动、承诺稳定的发行版。正因为如此，确保其核心服务的安全就显得尤为重要。这次修复，不仅仅是一次简单的yum update，更是一次检验我们运维流程、备份策略和应急响应能力的实战。本文将基于我在多台Rocky Linux 9服务器上的实际修复经历，详细拆解从漏洞分析、修复方案选择、到具体操作步骤、回滚预案以及修复后验证的全过程。无论你是刚接触Rocky Linux的新手，还是经验丰富的系统管理员，都能从中找到可直接复用的操作指南和避坑心得。

2. 漏洞核心解析与修复策略制定

在动手之前，我们必须先搞清楚我们要对付的是什么。CVE-2024-6387，官方名称为“regress”，是OpenSSH服务器（sshd）中存在的一个安全缺陷。它的本质是一个信号处理相关的竞争条件漏洞。在特定的、非默认的配置和网络条件下，攻击者可能通过精心构造的连续连接请求，触发这个竞争条件，最终导致sshd进程崩溃，甚至在理论上存在执行任意代码的可能性。

注意：不要被“非默认配置”和“特定条件”所迷惑而掉以轻心。安全漏洞的严重性评估（CVSS评分）往往综合考虑了利用难度和潜在影响。对于OpenSSH这种暴露在公网、权限极高的服务，任何可能导致远程代码执行（RCE）的漏洞，无论利用链多复杂，都应被视为高危漏洞立即处理。

那么，修复的核心思路是什么？最直接、最官方、最推荐的方法就是升级OpenSSH软件包到已修复该漏洞的版本。对于Rocky Linux而言，这意味着依赖其上游——Red Hat Enterprise Linux (RHEL) 的安全更新流。RHEL安全团队在漏洞披露后，会迅速测试并发布包含修复补丁的软件包更新，Rocky Linux社区则会几乎同步地重建并发布这些更新。

因此，我们的修复策略非常明确：

1. 通过官方仓库升级：使用dnf或yum包管理器，从Rocky Linux的官方更新仓库（如baseos,appstream,crb）直接安装已修复漏洞的OpenSSH更新包。这是最安全、最稳定、兼容性最好的方式。
2. 编译安装（最后手段）：仅在极端情况下，例如官方仓库因网络或镜像问题暂时不可用，且业务紧急程度极高时考虑。但这会引入依赖管理、后续升级复杂化等一系列问题，不推荐用于生产环境。

我们的操作将严格遵循第一种策略。整个流程可以概括为：检查当前版本 -> 备份关键配置 -> 更新软件包 -> 重启服务 -> 验证修复。下面，我们就进入具体的实操环节。

3. 修复前至关重要的准备工作

在按下回车键开始升级之前，充分的准备工作能避免90%的灾难。这一步绝不能跳过。

3.1 环境状态检查与记录

首先，我们需要建立一个“快照”，清晰了解升级前的系统状态。

1. 检查当前OpenSSH版本及漏洞状态：

# 查看当前安装的openssh-server版本 ssh -V # 输出示例：OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022 # 更详细的信息 rpm -qa | grep -E \"openssh-(server|clients)\" # 输出示例：openssh-server-8.7p1-29.el9_2.x86_64

记录下这个版本号，这是验证升级是否成功的基准。

2. 检查系统版本和仓库配置：

# 确认是Rocky Linux 9 cat /etc/redhat-release # 检查可用的更新仓库 dnf repolist enabled

确保你的系统订阅了baseos和appstream等核心仓库。通常默认安装后就是启用的。

3. 备份！备份！备份！这是铁律。我们要备份两部分内容：

• SSH服务配置文件：/etc/ssh/sshd_config。这是所有自定义配置（如端口、禁用密码登录、AllowUsers等）所在之处。

sudo cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d)

• 整个/etc/ssh目录（可选但推荐）：以防升级过程中其他相关文件发生变化。

sudo tar -czf /root/ssh_backup_$(date +%Y%m%d).tar.gz -C /etc ssh/

4. 确保有一个不受SSH升级影响的维护通道：这是最容易被忽略，也最关键的一步。想象一下，你通过SSH连接到服务器，执行升级并重启了sshd服务，如果新版本的服务因为任何原因（如与你自定义配置冲突）启动失败，你的当前连接可能会中断，并且你将无法重新连接，导致服务器“失联”。

• 物理控制台：如果有条件，直接在服务器本地操作。
• 带外管理（IPMI/iDRAC/iLO）：通过服务器的硬件管理接口连接，这是最可靠的备用方案。
• 串口控制台：在云平台或虚拟化环境中配置。
• 临时启用其他远程访问方式：例如，在非常短的时间窗口内，启用一个受严格限制的Telnet服务（仅限特定IP），或者确保VNC服务已就绪。但这会引入新的安全风险，需谨慎评估并事后立即关闭。

实操心得：在生产环境中，我强烈建议通过服务器的硬件管理口（如Dell的iDRAC， HPE的iLO）进行操作。即使SSH完全崩溃，你依然能像坐在机器前一样操作。如果没有硬件管理口，在云平台上，确保你配置了“救援模式”或“串口控制台”功能，并提前测试过可用性。

3.2 制定回滚方案

即使官方更新包经过测试，也存在极小的概率与你的特定环境发生冲突。因此，必须明确如何快速回滚。

1. 软件包回滚：如果更新后发现问题，可以尝试降级到旧版本。

   # 查看可用的openssh-server版本历史 dnf list --showduplicates openssh-server # 如果更新后需要回滚 sudo dnf downgrade openssh-server-<旧版本号>

2. 配置回滚：如果问题出在配置上，直接用备份文件覆盖。

   sudo cp -p /etc/ssh/sshd_config.backup.<日期> /etc/ssh/sshd_config sudo systemctl restart sshd

3. 快照回滚（最佳）：如果服务器运行在虚拟机（VMware, KVM, 公有云）上，在升级前为虚拟机创建一个快照。这是最干净、最彻底的回滚方式，几秒钟就能完成。

4. 分步执行漏洞修复操作

准备工作就绪，我们可以开始正式的修复操作了。整个过程需要在有sudo权限的用户下进行。

4.1 更新系统仓库索引

首先，确保本地的包元数据是最新的，这样才能获取到最新的安全更新信息。

sudo dnf makecache

这个命令会从配置的所有仓库下载最新的软件包列表和元数据。在带宽较小或仓库同步延迟的环境下，可能需要一点时间。

4.2 检查可用更新

在正式升级前，先查看一下有哪些关于OpenSSH的更新可用。

sudo dnf check-update openssh*

或者查看所有安全更新：

sudo dnf --security check-update

输出会列出可升级的软件包及其新版本号。你应该能看到openssh-server,openssh-clients等包的新版本。记下版本号，例如从8.7p1-29.el9_2升级到8.7p1-30.el9_2。版本号中el9_2表示这是针对RHEL 9.2（及对应Rocky Linux 9.2）构建的，后面的数字递增通常包含了安全补丁。

4.3 执行OpenSSH升级

现在，执行升级命令。我推荐使用dnf upgrade并指定包名，而不是dnf update全部更新，这样变更范围更可控。

sudo dnf upgrade openssh-server openssh-clients openssh

dnf会解析依赖关系，列出所有将要安装、升级或删除的软件包。请仔细阅读这个列表！确保没有你不期望的额外变更（例如，因为依赖关系而升级了某些重要的底层库）。确认无误后，输入y并回车开始下载和安装。

关键点解析：为什么是openssh-server,openssh-clients,openssh？openssh是一个元包，通常依赖于server和clients。单独升级server和clients可以确保两端都得到修复，避免因版本不一致可能出现的兼容性问题。同时升级元包能保持包管理的整洁。

4.4 验证升级结果

安装完成后，立即验证版本是否已更新。

ssh -V rpm -qa | grep openssh-server

对比之前记录的版本号，确认版本号已递增。例如，看到openssh-server-8.7p1-30.el9_2.x86_64即表示成功。

4.5 重启SSH服务并确保其正常启动

升级软件包并不会自动重启服务。旧的sshd进程仍在内存中运行着带有漏洞的旧代码。必须重启服务以使新版本生效。

sudo systemctl restart sshd

重启后，至关重要的一步是检查服务状态，确保它没有因为配置错误而启动失败。

sudo systemctl status sshd

你期望看到的状态是active (running)，并且下面没有红色的failed或error日志。如果有任何问题，journalctl -u sshd可以查看详细的日志。

4.6 进行连接测试

不要假设服务重启了就万事大吉。你需要从另一个终端（务必使用之前准备的备用通道，或者确保当前连接不会因测试中断）发起一个新的SSH连接，测试登录是否正常。

# 从另一台机器测试 ssh username@your_server_ip

同时，检查你现有的SSH会话是否稳定。有时服务重启不会踢掉已有连接，但最好确认一下。

5. 修复后的全面验证与加固

升级并重启服务只是第一步，我们需要确认漏洞确实被修复了，并借此机会审视一下SSH的安全配置。

5.1 漏洞修复确认

最权威的确认方式是检查软件包发布的更新日志（changelog）。

rpm -q --changelog openssh-server | head -30

在输出的更新日志中，寻找包含CVE-2024-6387或regress字样的条目。如果找到了，就明确证明这个更新包包含了针对该漏洞的补丁。这是比单纯看版本号更可靠的验证方法。

5.2 安全配置复查（黄金机会）

一次安全漏洞修复，是复查相关服务安全配置的绝佳时机。我们检查一下/etc/ssh/sshd_config中的几个关键项：

sudo cat /etc/ssh/sshd_config | grep -E \"^(Port|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|Protocol)\"

• Port：是否已从默认的22端口改为非标准端口？这能减少自动化扫描的骚扰。
• PermitRootLogin：是否设置为no或prohibit-password？禁止root直接密码登录是基本要求。
• PasswordAuthentication：是否设置为no？对于服务器，强烈建议禁用密码登录，全面使用密钥认证，这能从根本上杜绝暴力破解。
• PubkeyAuthentication：是否设置为yes？确保密钥认证已开启。
• AllowUsers或AllowGroups：是否设置了访问白名单？进一步缩小攻击面。
• Protocol：是否只使用了2？SSH协议1早已不安全，必须禁用。

如果升级过程中配置文件被新包提供的配置文件覆盖（通常rpm会保留你修改过的配置，并以.rpmnew形式提供新配置样本），你需要合并更改。用sudo ls -la /etc/ssh/sshd_config*查看是否有sshd_config.rpmnew文件，如果有，需要手动比较并合并必要的安全设置。

5.3 系统完整性检查

升级后，进行一次快速的整体检查是个好习惯。

# 检查是否有其他服务依赖openssh的库，并测试它们（例如，某些自动化脚本） sudo lsof | grep libssh # 检查系统日志，看升级后有无异常报错 sudo journalctl --since \"1 hour ago\" -p err

6. 常见问题与故障排查实录

在实际操作中，你可能会遇到以下问题。这里记录了我的排查思路和解决方法。

6.1 升级过程中依赖冲突或错误

问题现象：执行dnf upgrade openssh-server时，报错提示依赖关系不满足或某软件包冲突。排查思路：

1. 检查仓库状态：sudo dnf repolist all，确保baseos和appstream仓库是启用且可用的。有时镜像同步问题会导致依赖包版本不对应。
2. 清理缓存并重试：sudo dnf clean all && sudo dnf makecache。然后再次尝试升级。
3. 查看详细错误：错误信息通常会给出冲突的包名。尝试使用dnf的解决能力：sudo dnf upgrade --allowerasing。但这个命令会允许删除冲突的包，非常危险！你必须仔细查看它会删除什么，确保不是关键系统包。
4. 考虑系统版本：你是否混合了不同版本的仓库（如同时有Rocky Linux 9和8的仓库）？确保/etc/yum.repos.d/下的repo文件配置正确。

实操心得：我曾遇到一个案例，是因为第三方EPEL仓库中的某个包版本与Rocky Linux 9 baseos仓库中的openssh更新产生了冲突。临时禁用EPEL仓库（sudo dnf --disablerepo=epel upgrade openssh-server）完成了OpenSSH的安全更新，然后再处理EPEL的依赖问题。这提醒我们，更新核心系统包时，最好在纯净的官方仓库环境下进行。

6.2 服务重启失败

问题现象：执行sudo systemctl restart sshd后，systemctl status sshd显示failed。排查思路：

1. 查看具体错误：sudo journalctl -u sshd -xe --no-pager会输出最近的相关日志，通常末尾几行会明确告诉你失败原因，例如“Configuration file /etc/ssh/sshd_config line 58: Bad configuration option”。
2. 检查配置文件语法：sudo sshd -t。这个命令会测试配置文件的语法，而不实际启动服务。它能精准定位到哪一行配置有问题。
3. 常见原因：
   • 配置参数拼写错误：仔细检查sshd_config中你修改过或新增的行。
   • 新版本弃用了旧参数：OpenSSH新版本可能会弃用某些旧参数。检查更新日志或官方文档。这时需要参考sshd_config.rpmnew（如果有）中的新写法。
   • 权限问题：/etc/ssh/sshd_config的权限应为600，属主为root。检查/var/empty/sshd目录是否存在且权限正确。
4. 回滚配置：如果一时找不到问题，立即用备份的配置文件恢复：sudo cp /etc/ssh/sshd_config.backup.<日期> /etc/ssh/sshd_config，然后重启服务。先恢复服务，再慢慢排查配置差异。

6.3 升级后无法连接

问题现象：服务显示active (running)，但无法从远程建立新的SSH连接。排查思路：

1. 检查网络和防火墙：

   # 确认sshd在监听正确端口 sudo ss -tlnp | grep sshd # 检查防火墙规则（firewalld） sudo firewall-cmd --list-all # 检查SELinux状态和日志 sudo getenforce sudo tail -f /var/log/audit/audit.log | grep sshd

   确保防火墙允许了你SSH所使用的端口（默认22或你自定义的）。如果改了端口，防火墙规则必须同步更新。
2. 检查客户端兼容性：极少数情况下，服务器端OpenSSH版本大幅提升，可能与非常老旧的客户端不兼容。尝试从另一个现代系统（如另一台Linux或Windows 10/11的OpenSSH客户端）连接测试。
3. 检查密钥权限：如果你使用密钥登录，确保服务器上~/.ssh/authorized_keys文件及其父目录的权限设置正确（.ssh目录700，authorized_keys文件600）。
4. 启用详细日志：在sshd_config中临时增加LogLevel DEBUG，重启服务，然后通过journalctl -u sshd -f实时查看连接尝试的详细日志，里面通常包含了拒绝连接的具体原因。

6.4 如何验证漏洞是否真正存在（检测）

在修复前，你可能想确认自己的系统是否受影响。对于CVE-2024-6387，由于是竞争条件漏洞，编写可靠的远程检测脚本比较复杂，且可能对生产环境造成影响（如大量连接导致服务负载升高）。因此，不建议在生产系统上运行未经严格审核的漏洞检测脚本。

最安全、最标准的做法是：

1. 版本比对：根据NVD（国家漏洞数据库）或Rocky Linux/RHEL安全公告，确定受影响的OpenSSH版本范围。如果你的版本在此范围内，则推定受影响。
2. 使用官方安全扫描工具：使用像OpenSCAP这样的合规性扫描工具，配合RHEL/Rocky Linux的安全策略（SSG）进行扫描，它可以基于软件包版本准确判断CVE状态。

   # 安装openscap-scanner和scap-security-guide sudo dnf install openscap-scanner scap-security-guide # 运行针对CVE的扫描（需根据实际策略文件路径调整） sudo oscap xccdf eval --results results.xml --report report.html --profile xccdf_org.ssgproject.content_profile_standard /usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml

   在生成的报告report.html中查找相关CVE的评估结果。

7. 长期维护与自动化安全更新思考

一次漏洞修复是救火，建立长期的免疫系统才是根本。对于Rocky Linux这类企业级系统，我推荐以下实践：

1. 启用自动安全更新（谨慎评估）：对于开发测试环境或重要性较低的业务，可以启用dnf-automatic进行自动安全更新。

sudo dnf install dnf-automatic sudo systemctl enable --now dnf-automatic.timer

但对于核心生产系统，不建议完全自动更新。应该设置为自动下载但不安装（dnf-automatic可配置），然后由运维人员在维护窗口内手动审核并安装。

2. 建立定期的漏洞扫描与补丁管理流程：

• 每周或每半月，使用sudo dnf --security check-update检查安全更新。
• 订阅Rocky Linux或RHEL的安全公告邮件列表，第一时间获取漏洞情报。
• 使用Tenable Nessus, Qualys, OpenVAS等专业漏洞扫描器定期扫描内网资产。

3. 使用配置管理工具固化状态：如果你管理着大量Rocky Linux服务器，像Ansible, SaltStack, Puppet这样的工具可以让你用代码定义OpenSSH的版本和配置。修复漏洞时，你只需要更新Ansible Playbook中的版本号，然后推送到所有主机，实现批量、一致化的修复。

# 一个简化的Ansible任务示例 - name: Ensure OpenSSH server is at the latest secure version dnf: name: - openssh-server - openssh-clients state: latest notify: restart sshd - name: Ensure SSH daemon is running systemd: name: sshd state: started enabled: yes

4. 容器化与不可变基础设施：对于云原生环境，考虑将应用容器化。主机（Rocky Linux）的职责被简化为运行容器引擎（如Docker或Podman）和内核。主机系统的OpenSSH可以保持极简配置，甚至通过跳板机（Bastion Host）访问，减少暴露面。系统的安全更新可以通过替换整个主机镜像（不可变基础设施）来完成，这通常比在线更新更干净、回滚更简单。

修复CVE-2024-6387这样的漏洞，流程本身并不复杂，但围绕它展开的准备工作、验证工作和后续的思考，才真正体现出一个运维工程师的功底。安全是一个持续的过程，而不是一次性的任务。每一次应急响应，都应该让我们的体系变得更健壮一些。