事件概述：一次「连夜抢发」的紧急更新
11 月 5 日，OpenSSH 发布 10.6p2 紧急版本，修复编号为 CVE-2026-123158 的密码认证绕过漏洞。安全圈给它起了个直白的绰号——「SSHole」：在特定组合的 Linux 系统上，攻击者不需要知道任何账号密码，只要提交一个 257～1024 个字符的超长密码，就能以「本不允许密码登录」的账号身份通过 SSH 认证。OpenSSH 开发者 Damien Miller 在发布说明中解释了为何如此仓促：团队近期多次遇到 AI 代理在数小时内「重新发现」漏洞的情况，因此认为过长的 embargo 期只对攻击者有利。
这个缺陷的「年龄」比想象中大——问题根源可以追溯到 2016 年。报告人、Wakefield 研究员 Özgün Kültekin 用相当「笨」也相当有效的办法找到了它：把 sshd 在 glibc/musl 与 PAM/无 PAM 的全部组合下分别构建，然后向每个构建投放约 17600 次刻意构造的异常登录。所有组合都表现正常，只有一个组合「在该拒绝的时候同意了」——musl libc、未启用 PAM。
利用速度超出了很多人的预期。威胁情报厂商 Previdian 称，其 Alpine Linux 蜜罐在漏洞公开后数小时内就记录到 8 次登录尝试（来自同一来源），其中一次直接以 root 身份进入系统；Help Net Security 的报道称，蜜罐上的利用在公开后约 9 小时即得到确认。
漏洞原理：一个「*」号引发的误判
多家安全厂商与媒体援引的评分为 CVSS v3.1 8.1（AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H），漏洞类型为 CWE-394（意外的状态码或返回值）。它的触发依赖三个条件同时成立：
其一，目标账号在系统 shadow 口令文件中的密码字段是「*」——这在只允许密钥登录的账号、服务账号中非常常见，Alpine 从 3.16 起也用「*」锁定 root；其二，musl libc 的 crypt() 在收到超过 256 字节的超长口令时，不会返回正常哈希，而是返回「*」作为错误指示；其三，在未启用 PAM 的认证路径上，OpenSSH 会取系统中另一个账号的 $5$（SHA-256）或 $6$（SHA-512）密码哈希作为 salt 参与计算，于是 crypt() 返回的「*」与目标账号存储的「*」一模一样——OpenSSH 把这次「哈希比对一致」当成了认证通过。
换句话说，攻击者不需要知道或破解任何密码，一次「密码处理失败」被误判成了「密码正确」。OpenSSH 开发者的定位也很坦诚：问题不在 sshd 自身代码，而在于 sshd 与 musl libc 交互的「胶水层」，但它确实可以通过 sshd 加以利用。用 Alpine 公告的说法：能连上 SSH 端口的攻击者，「一次连接即可登录，不需要重试」。
影响范围：谁中招，谁不受影响
需要强调的是，这不是「所有 OpenSSH 都不安全」。触发绕过需要以下条件全部满足：OpenSSH 版本低于 10.6p2 且编译链接 musl libc；未启用 PAM；PasswordAuthentication 为 yes；存在 shadow 字段为「*」的账号；系统中至少还有一个 $5$ 或 $6$ 开头的密码哈希账号；且 SSH 端口对攻击者可达。
按这个标准，最典型的中招者是 Alpine Linux：其默认 openssh-server 包不带 PAM，且默认允许密码认证，受影响版本覆盖 3.16 到 3.24 及 edge。官方 tiny-cloud 镜像（3.18.11～3.24.3）更值得警惕——镜像内置的 alpine 账号拥有免密 doas 权限，意味着攻击者登录后可直接提权到 root。其他 musl 生态同样在射程内：OpenWrt、Buildroot、Yocto 以及大量以 Alpine 为基础镜像的容器（但只有确实运行着可达 sshd 的容器才暴露）。
不受影响的阵营同样清晰：使用 glibc 的发行版（Debian、Ubuntu、Fedora、RHEL 等）、启用 PAM 的 OpenSSH、Dropbear，以及非 Linux 平台的 OpenSSH。群晖 11 月 6 日发布的 Synology-SA-26:16 也明确 DSM 7.3/7.4、SRM 等产品不受影响。另外要注意，它与 2024 年轰动一时的 regreSSHion 竞态漏洞是两套完全不同的代码路径，不要混为一谈。
为什么普通用户和站长、运维要关注
Alpine 是容器世界流行度最高的基础镜像之一，「镜像很小、很干净」的背后是大量跑着 sshd 的 Alpine 小主机、边缘设备和 CI 环境。Detectify 联合创始人 Fredrik Almroth 提供了一个量化背景：Shodan 上约 2200 万台机器的 22 端口对外开放，真实数字只会更高——而这次攻击「一次连接、无需重试」，意味着扫描整个互联网的成本几乎为零。他自己的判断是：「如果到周末还没有看到爆破工具尝试这个漏洞，我们会非常惊讶。」
对个人用户来说，风险不只在服务器：刷了 OpenWrt 的路由器、自组的 Alpine 迷你主机，都可能落在受影响组合里。对企业来说，还有一个容易被忽略的点——镜像。只给运行中的容器打补丁，而 CI 流水线和镜像仓库里的基础镜像不重建，下一轮部署会把漏洞原样带回生产环境。
排查思路：先确认「我是不是那个组合」
排查按只读、低风险优先，建议顺序如下：
1）确认系统底子：是否为 Alpine（cat /etc/alpine-release）、OpenWrt、Buildroot/Yocto 或自建 musl 系统；2）确认 sshd 版本（sshd -V 或 ssh -V）是否低于 10.6p2，以及是否启用了 PAM（检查 /etc/pam.d/sshd 与配置中的 UsePAM）；3）确认 sshd 配置中 PasswordAuthentication 是否为 yes；4）抽查系统 shadow 口令文件，确认是否存在密码字段为「*」的账号，以及是否存在 $5$/$6$ 开头的哈希账号；5）翻系统日志（如 /var/log/messages），搜索 "Accepted password"，重点核对「本不允许密码登录的账号出现了密码登录记录」，并结合来源 IP、登录时间做交叉判断；6）盘点镜像仓库与 CI 模板中的 Alpine 基础镜像版本。
修复与缓解建议：以官方公告为准
首选方案是升级到 OpenSSH 10.6p2 或各发行版的修复包。Alpine 已为全部分支提供修复包：edge 10.6_p2-r0、3.24 10.3_p1-r2、3.23 10.2_p1-r1、3.22 10.0_p1-r11、3.21 9.9_p2-r1、3.20 9.7_p1-r6、3.19 9.6_p1-r3、3.18 9.3_p2-r4、3.17 9.1_p1-r7、3.16 9.0_p1-r6，点版本 3.21.10/3.22.8/3.23.8/3.24.4 亦包含修复。
有两个关键细节来自 Alpine 官方提醒：其一，升级软件包不会替换正在运行的 sshd，必须重启服务后修复才生效；其二，如果暂时无法升级，可将 PasswordAuthentication 设为 no 并重启 sshd 作为缓解——操作时请先开启第二个会话确认密钥登录正常，再关闭当前会话，避免把自己关在门外。重启生产服务器 sshd 前，请评估业务影响并选择维护窗口，事先备份 /etc/ssh 配置。
容器与镜像环境：从修复后的基础镜像重新构建并重新部署，不要只修运行中的实例；同时收敛暴露面，非必要不将 22 端口直接置于公网（调整防火墙或安全组前先备份规则、评估远程运维通道）。失陷处置方面，一旦发现无法排除的「无密码账号密码登录」，应按已失陷假设处理：先保全证据或镜像，再重建系统，并轮换该主机上的部署密钥、访问令牌等凭据。
最后提醒：漏洞细节与利用复现已经公开，社交平台上势必出现来路不明的 PoC 和「检测脚本」，不要随意克隆执行，一切以 OpenSSH 官方发布与发行版官方包为准。
后续观察
几个值得持续跟踪的点：一是 CISA KEV 目录截至 11 月 4 日核对的版本尚未收录该漏洞，但蜜罐已确认遭利用、细节完全公开，扫描很可能已经铺开，KEV 动向值得关注；二是针对生产环境的实际受害报告尚未出现，Alpine 的口径是「尚未看到利用报告」，蜜罐上的 root 得手证明的是「从公开到武器化只用了几个小时」，而非大规模攻击已经开始；三是 OpenSSH 对「AI 加速漏洞再发现」的表态，预示着未来紧急发布会更频繁，对运维来说，补丁流程的响应速度本身就是一道安全题。
一句话总结：SSHole 的触发条件不算宽，但踩中这个组合的系统（尤其是默认配置的 Alpine）几乎没有防护纵深可言。今晚值得做的事只有两件——确认自己是不是那个「musl 无 PAM + 密码认证」组合，如果是，升级、重启、查日志。
暂无评论内容