内容摘要：```html OpenSSH 9.8p1 发布那天，我正蹲在一台跳板机上排查一个诡异的登录延迟。日志里反复出现 ssh_dispatch_run_fatal: Connection from 10.

```html

OpenSSH 9.8p1 发布那天，洞修我正蹲在一台跳板机上排查一个诡异的洞修登录延迟。日志里反复出现 ssh_dispatch_run_fatal: Connection from 10.0.3.17 port 51234: message authentication code incorrect。洞修起初以为是洞修网络抖动，换了两台交换机、洞修抓了三次包，洞修最后才发现是洞修 CVE-2024-6387 的前兆——那个被称作 regreSSHion 的漏洞，允许攻击者在特定条件下远程执行代码。洞修

修复这件事，洞修最忌讳的洞修是“升级完就完事”。我见过太多人 apt upgrade openssh-server 之后重启服务，洞修然后拍拍手走人。洞修实际上，洞修OpenSSH 的洞修漏洞修复牵扯到三个层面：二进制版本、配置项兼容、洞修以及 sshd 进程的实际行为。少查一个，就可能留个后门给自己。

先确认你跑的是哪个版本

别信 ssh -V 的输出。那玩意儿显示的是客户端版本，跟服务端没半点关系。真正要看的是 sshd 二进制：

sshd -V 2>&1 | head -1 # 或者 /usr/sbin/sshd -V

如果输出里带着 “OpenSSH_9.7p1” 或者更早，且你的发行版没有打回补丁，那 regreSSHion 就悬在头顶。Debian 12 默认是 9.2p1，但 Debian 的安全团队在 7 月 1 日就发了 9.2p1-2+deb12u2，修复了信号处理逻辑。Ubuntu 22.04 的 8.9p1 也在 7 月 2 日推了 8.9p1-3ubuntu0.10。关键不是版本号大小，而是发行版有没有 backport 那个补丁。

我习惯用 dpkg -l openssh-server 或 rpm -q openssh-server 看包版本，然后对照发行版的安全公告。比如 Debian 的 DSA-5724-1，Ubuntu 的 USN-6859-1。别去 GitHub 上翻 commit，效率太低。

升级之后，sshd 可能根本没重启

这是最阴的坑。你在 Debian 上 apt upgrade，包管理器会提示 “openssh-server: restarting sshd”。但如果你用的是 systemd，它可能只是重新加载了配置，没杀掉旧进程。旧进程还跑着有漏洞的代码。

验证方法：

ps -eo pid,lstart,cmd | grep '[s]shd' # 看进程启动时间，如果早于你升级的时间，就是没重启

更稳妥的做法是 systemctl restart sshd，但注意——如果你是通过 SSH 连上去的，重启会断你连接。用 tmux 或者 nohup 包一下，或者干脆写个 at 任务延迟几秒执行。我吃过这个亏，在阿里云的一台 ECS 上直接 systemctl restart sshd，结果连接断了，控制台又没配 VNC，最后提工单让客服重启的。

配置层面：LoginGraceTime 不是万能药

很多文章说把 LoginGraceTime 改成 0 就能缓解 regreSSHion。确实，漏洞触发需要 sshd 在未认证状态下等待超过默认的 120 秒。改成 0 意味着永不超时？不对，改成 0 是禁用超时，反而更糟。正确的临时缓解是改成 30 秒或更短，比如 LoginGraceTime 20。但这只是拖延，不是修复。

另外检查 MaxStartups。默认 10:30:100 意味着最多 10 个并发未认证连接。攻击者可以利用这个窗口。我一般会收紧到 MaxStartups 3:50:10，配合 PerSourceMaxStartups 1。别照抄，根据你实际用户量调。我们内网跳板机就 20 几个人用，设成 3 完全够。

别忽略 sshd_config 里的 Include

OpenSSH 8.2 之后支持 Include /etc/ssh/sshd_config.d/*.conf。有的发行版默认开了这个。你改完主配置文件，结果某个 50-cloud-init.conf 把 PasswordAuthentication 又打开了。我见过一台机器，主配置里写了 PermitRootLogin no，但 sshd_config.d/ 下面有个文件写了 PermitRootLogin yes。sshd 读配置是按顺序的，后面的覆盖前面的。

用 sshd -T 输出最终生效的配置，别靠眼睛看。这个命令会打印所有实际生效的选项，包括 Include 进来的。我每次改完配置都跑一遍 sshd -T | grep -E 'permitrootlogin|passwordauth|logingracetime'，确认没有意外覆盖。

最后，别把 SSH 端口暴露在公网

这话听起来像废话，但我扫过不少客户的资产，22 端口直接对 0.0.0.0 开放，连 fail2ban 都没装。regreSSHion 的利用条件虽然苛刻——需要特定 glibc 版本、需要大量连接尝试——但攻击者有的是时间。放到非标准端口、加个防火墙白名单、或者干脆用 WireGuard 做一层隧道，比任何补丁都实在。

我自己的跳板机只允许公司 VPN 段访问，sshd 监听在 2222 端口，fail2ban 的 maxretry 设成 3，bantime 设成 86400。两年了，日志里除了我自己的 IP，没见过别的。

修复不是一锤子买卖。升级、重启、验证配置、收紧访问，四步做完再收工。少一步，你今晚可能就睡不着了。

```