OpenSSH 紧急发布 10.6p2：musl 系统上 257–1024 字节密码可绕过认证免密登录

OpenSSH 项目 11 月 5 日紧急发布 10.6p2，修复一个可经 sshd 触发的认证绕过：在用 musl libc 构建、且 PAM 支持关闭的 Linux 系统（Alpine、OpenWrt、Buildroot、Yocto 等）上，攻击者提交任意 257–1024 字节的密码，就能以密码方式登录 shadow 字段为 * 的无密码账号——包括仅限密钥登录的账号。OpenSSH 将其定为 critical；Alpine 已为 3.16 起全部支持分支发出修复包；glibc 系统不受影响。官方 release notes 原文称，这是「password authentication bypass that is exploitable through sshd(8)」，条件是系统「built and run with PAM support disabled」。

要点

• 触发条件是四个叠加：sshd 以无 PAM 方式构建并运行、开启密码登录（PasswordAuthentication yes，默认即开）、存在密码字段为 * 的账号、系统里还有至少一个 $5$/$6$ 哈希的真实账号——据 The Hacker News 转引的 Alpine 公告，四个条件全满足时「单次连接即可每次都成功」。
• 机制是两处历史改动的耦合：musl 2012 年让 crypt() 失败时返回错误标记 *，随后给 sha512crypt 加了 256 字节密码上限；OpenSSH 2016 年为修时序侧信道（CVE-2016-6210）引入借盐逻辑。超长密码哈希失败返回 *，正好等于存储的 *，登录放行。
• 官方修复是 sshd 侧的 workaround：10.6p2 拒绝「存储字段短于 4 字符」的匹配；OpenSSH 明言根因在 sshd 之外。CVE 尚未分配，目前也暂无在野利用报告。

背景

这不是 sshd 新引入的缺陷，而是三个互不相干的历史决定在 2026 年撞到了一起。第一件在 musl 侧：2012 年，musl 为避免程序不检查 NULL 返回值而崩溃，让 crypt() 失败时返回错误标记 *——发现者在技术分析里写道「yep. the star. again.」；二十天后 musl 又给 sha512crypt 加了 256 字节的密码上限，超过即失败，而失败就返回 *。第二件在 OpenSSH 侧：2016 年修 CVE-2016-6210（用户名枚举时序侧信道）时，sshd 对没有真实哈希可比对的账号，借另一个账号的盐照样哈希一遍，把响应时间耗平——这条路径同样覆盖密码字段为 * 的真实用户。第三件在 Alpine 侧：2022 年前后，Alpine 把 root 的锁定标记从 ! 改成 *（本意是让 root 的 SSH 密钥登录继续可用），默认镜像里 root 的密码字段从此就是 *。发现者 Özgün Kültekin 在分析里把这三步串成完整因果链，标题起得很直白：「accounts that should never take a password at all … take any password longer than 256 characters」。

事实部分

绕过的成立条件与影响面，各来源口径一致。据 The Hacker News 转引的 Alpine 公告，四个条件全部满足时攻击「succeeds on every try with a single connection」：

项目	内容
受影响	musl libc 系统：Alpine（默认构建满足条件）、OpenWrt（另行安装 OpenSSH 时）、Buildroot、Yocto
不受影响	glibc 系统、PAM 启用的构建、PasswordAuthentication no 的机器、不含 sshd 的容器、密码字段为 ! 的锁定账号
触发密码长度	257–1024 字节（上限是 sshd 自身的密码长度限制）
修复版本	OpenSSH 10.6p2（2026-11-05）；Alpine 点版本 3.21.10 / 3.22.8 / 3.23.8 / 3.24.4，修复回溯到 3.16
严重程度	OpenSSH 定为 critical；CVE 编号尚未分配
在野利用	暂无攻击报告

暴露面里最容易踩到的是无密码账号：仅密钥登录的账号、经 musl-nscd 挂进来的目录服务账号，以及 Alpine 3.16 起默认 root:* 的 root 账号。The Hacker News 同时提醒，默认的 PermitRootLogin prohibit-password 会拦掉 root 的密码登录，前提是管理员没改过这项配置。tiny-cloud 镜像（3.18.11–3.24.3）里的默认用户 alpine 最危险：登录后可用免密 doas 提权，等于直接拿到完整 root。发现者公布的 PoC 截图演示了全过程：先用错误密码被拒，再提交一串 257 字节以上的 A，登录成功，id 显示 uid=0(root)。OpenWrt 默认的 Dropbear 不受影响，但装了 OpenSSH 的设备要自查；Buildroot 和 Yocto 系统同样在排查清单上。

各方说法

OpenSSH 的 Damien Miller 对受影响用户说得最直白——立即「set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY」。他还解释了为什么这次放弃长期保密：团队现在认为长 embargo 危险，部分原因是 AI 代理最近会在数小时内重新发现同样的 bug——同一趋势我们在 OpenAI 自主管线挖出 948 个内核提权 exploit 里已经见过一次。发现者 Özgün Kültekin（Wakefield）的方法论值得一记：他把 sshd 按 glibc/musl × PAM/无 PAM × shadow/无 shadow 的矩阵逐一构建，用「agent swarms」跑了约 17,600 次异常登录尝试，结果只有 musl-无 PAM 组合接受了不该接受的密码——这基本排除了其他路径的嫌疑。中文侧，IT之家 11 月 6 日转载并确认了同一组数字：257–1024 字节触发、musl 系统受影响、升级 openssh 包即可修复；glibc 不受影响这一点出自 OpenSSH 官方公告与 The Hacker News 的报道。检测口径官方与发现者一致：日志里出现针对 root、alpine 或仅密钥账号的 Accepted password for，就该按已入侵处理。

修复与检测

Alpine 的修复路径是一条命令加一步重启——只升级不重启，内存里跑的还是旧 sshd 进程：

apk upgrade -U -a
rc-service sshd restart

暂时不能升级的系统，先确认密钥登录可用、保持当前会话不断开，再把 PasswordAuthentication 设为 no，用 sshd -t 验语法，重启后用 sshd -T | grep -i passwordauthentication 确认输出为 no。事后核查按 Alpine 公告的口径：在 /var/log/messages 里搜 Accepted password for，凡是落到无密码账号（root、alpine、仅密钥账号）的记录都视为成功入侵，再逐项查 doas 使用记录、新增用户、可疑文件和 authorized_keys。公告原话是「If you cannot rule out a login, treat the machine as compromised」——无法排除登录，就按已入侵处理。

编辑判断

对拿 Alpine 做底座的容器与镜像维护者，这件事的教训不在「赶紧升级」，而在默认组合的耦合故障：三个各自合理的决定——musl 的防崩溃返回值、sshd 的防时序借盐、Alpine 的 root 锁定方式——叠出了一个 critical。任何一环换掉（glibc、PAM、! 锁定）都不成立，这也正是排查时先看的那几项。要留余地的是两处：其一，修复本身是 sshd 侧的 workaround，根因在 musl 侧怎么改、何时改，官方没给时间表；其二，别把警报扩大——glibc 系统和不含 sshd 的容器不受影响，真正要动的是跑着 musl sshd 且开着密码登录的机器。这类 bug 与 IEEE Spectrum 的 PHP2Shell 复盘 是同一类休眠风险：多年前埋下的组合，等一个恰好会走这条路的人；PHP 本月修复的两个 CVSS 9.2 RCE 同理——发现侧越来越快，修复侧的响应速度才是真正的变量。

接下来

三个可盯的信号：CVE 编号的分配与最终描述；musl 侧对根因的处置（OpenSSH 明言「root cause outside sshd」，但没给时间表）；以及 OpenWrt、Buildroot、Yocto 这些非 Alpine 的 musl 系统何时跟进各自的包更新。对运维侧，Damien Miller 透露的 embargo 政策收紧值得当作新常态：漏洞从发现到公开的窗口会越来越短，密码登录这种一个开关就能关掉的攻击面，优先关掉。