在部分运行标准 openssh-server 软件包的 Alpine Linux 服务器上，攻击者可以绕过认证，直接登录无密码账户——比如仅配置了 SSH 密钥登录的账户。攻击者只需要具备服务器的网络访问权限、掌握目标账户名，再输入一段 257 到 1024 字节之间的超长密码，就能完成登录。
OpenSSH 官方将该漏洞评级为严重，并紧急发布了 10.6p2 版本封堵该问题。Alpine 也已为所有 3.16 及以上版本推送了修复包。
这一攻击的触发需要同时满足三个前置条件：OpenSSH 服务端（sshd）未通过 PAM 接口校验密码、已开启密码登录、设备上至少存在一个设置了密码的账户。而 Alpine 的 openssh-server 软件包默认编译时未启用 PAM 支持，密码登录功能也默认开启，恰好为攻击者创造了可乘之机。
OpenSSH 项目的 Damien Miller 表示，漏洞根源在于 sshd 与 Alpine 底层使用的 C 语言库 musl 之间的交互逻辑问题。非 Linux 系统、基于 glibc 的 Linux 系统，以及通过 PAM 校验密码的系统均不受影响。
Miller 建议所有运行受影响系统的管理员："立即设置 PasswordAuthentication=no，或直接禁用这些系统的 SSH 服务。"目前尚未发现利用该漏洞发起的在野攻击。
Part 01：四类条件同时满足即暴露
Alpine 发布的安全公告列出了四项判定条件，服务器同时满足所有条件时即存在风险：
- 运行未启用 PAM 编译的
openssh-server 软件包，或运行 openssh-server-pam 但配置了 UsePAM no。
PasswordAuthentication 配置为 yes，这是 OpenSSH 的默认值。- 存在密码字段为
* 的账户，即未设置密码的账户。
- 至少有一个本地账户的密码哈希以
$5$ 或 $6$ 开头。
攻击者还需要掌握一个无密码账户的用户名。只要设备上存在一个设置了密码的账户，所有无密码账户都会随之暴露。公告显示，该攻击单次连接就能 100% 成功。
在 Alpine 系统中，无密码账户主要包含以下几类：
- 通过
adduser 命令未设置密码创建的仅密钥登录用户，或通过 usermod -p '*' 命令配置的用户。
- 通过
musl-nscd 从目录服务同步的用户，这类用户没有 shadow 条目。
- root 账户：从 Alpine 3.16 版本开始，基础镜像中的 root 账户默认配置为
root:*。
- 使用 tiny-cloud 构建的官方云镜像中的
alpine 用户。
root 账户受默认配置 PermitRootLogin prohibit-password 保护，只有管理员主动设置 PermitRootLogin yes 时才能直接登录 root。但如果可被攻击的账户能通过 doas 等方式提权至 root，这层保护就会失效。
以 3.18.11 到 3.24.3 版本的 tiny-cloud 镜像为例，默认为 alpine 用户配置了免密 doas 权限。这类镜像首次启动时是安全的，但一旦设备上出现任意 $6$ 哈希——比如管理员设置控制台密码之后——就会立刻面临攻击风险。攻击者可以先登录 alpine 账户，再借助 doas 提权至 root。
未运行 sshd 的容器、配置了 PasswordAuthentication no 的系统，以及通过 cloud-init 初始化（会自动写入该配置）的云镜像均不受影响。/etc/shadow 中密码字段为 ! 的锁定账户不受影响，不存在任何 $ 格式密码哈希的设备同样不受影响。
值得注意的是，这个漏洞并非 Alpine 独有。安全/渗透/逆向 领域的研究员 Özgün Kültekin 在技术分析中指出，其他基于 musl 的系统——包括 OpenWrt、Buildroot、Yocto——也需要开展排查。OpenWrt 的文档显示，系统默认使用 Dropbear 处理 SSH 连接，而 Dropbear 已被确认不受该漏洞影响。只有当管理员在 OpenWrt 上手动安装 OpenSSH 服务端时，才可能存在相关风险。
Part 02：升级软件包重启服务可修复
在 Alpine 系统上，修复流程并不复杂，核心就是先更新软件包，再重启服务。需要注意，升级软件包不会自动重启正在运行的 sshd 进程，所以两步缺一不可。
更新软件包：
apk upgrade -U -a
重启 sshd 服务：
rc-service sshd restart
3.21.10、3.22.8、3.23.8、3.24.4 这几个点发布版本已预装修复后的软件包。3.16 到 3.21 分支虽已过支持周期，但也同步推送了修复包。
若云实例基于版本号低于上述点发布版的 tiny-cloud 镜像创建，仍需手动更新，或采用下文的配置缓解方案。如果是自行编译 OpenSSH 的用户，10.6p2 版本已包含该修复补丁。
如果暂时无法升级，关闭密码登录功能也能有效阻断攻击。操作前务必确认 SSH 密钥登录正常，并且在验证新登录成功之前不要关闭当前会话。之后设置 PasswordAuthentication no，通过 sshd -t 检查配置无误，再重启 sshd 服务即可生效。
安全公告提供了相关的配置命令，可以在 /etc/ssh/sshd_config.d 目录下新增配置片段——Alpine 3.19 及以上版本的默认配置会自动读取该目录下的文件。配置完成后，执行以下命令验证：
sshd -T | grep -i passwordauthentication
输出结果应为 passwordauthentication no。
公告还建议管理员检查 /var/log/messages 日志，查找 sshd 进程输出的 Accepted password for 记录，确认是否有无密码账户（如 alpine、root 或仅密钥登录用户）被异常登录。对于已暴露的设备，还需要排查 doas 使用记录、近期新建的用户、文件及授权密钥。公告明确指出："如果无法排除已被登录的可能，需按设备已失陷进行处置。"
Part 03：长密码触发 musl 库报错，哈希比对逻辑被绕过
未启用 PAM 时，sshd 会自行完成密码校验。它调用 C 库函数 crypt() 将用户输入的密码转换为存储格式的哈希值，再与账户存储的密码字段进行比对。
无密码账户的密码字段仅为 *，长度过短无法存储哈希所需的随机盐值，因此 sshd 会借用其他有有效哈希账户的盐值来完成计算。问题恰恰出在这里——对于 $5$ 和 $6$ 类型的哈希，musl 的 crypt() 函数会拒绝处理长度超过 256 字节的密码，并返回 * 表示错误。这个返回值刚好和无密码账户存储的 * 匹配，sshd 就会误判认证通过，允许登录。而可利用的密码长度上限为 sshd 自身设定的单密码 1024 字节限制。
这一问题可以追溯到 musl 库 2012 年 8 月 9 日的一次变更：当时由于大量程序未校验 crypt() 调用失败的情况，开发团队将调用失败的返回值从 NULL 改为"不可匹配的哈希值"。同年 8 月 29 日，musl 又新增了 256 字节的密码长度限制，用于防范拒绝服务攻击。
而 sshd 借用盐值的逻辑，则来自 2016 年 7 月 15 日 OpenSSH 为修复 CVE-2016-6210 所做的变更——该漏洞允许攻击者枚举系统中存在的用户名。Özgün Kültekin 指出，本次的认证绕过问题从那时起就已存在。
10.6p2 版本的代码修改为：当账户存储的密码字段长度短于 4 个字符时，sshd 直接判定比对不通过。OpenSSH 表示这只是临时缓解方案，根本原因不在 sshd 本身。Alpine 的稳定版软件包也搭载了针对该问题的补丁。
Part 04：团队快速响应发布修复
Damien Miller 带领的团队本周早些时候获悉该漏洞，第一时间开发并推送了修复补丁。他在发布公告中表达了团队对漏洞保密策略的反思："团队现在认为，长时间的漏洞保密期存在风险，反而主要给攻击者提供便利。因为近期我们观察到，AI Agent 仅需数小时就能重新发现同类漏洞。"
截至发稿时，该漏洞尚未分配 CVE 编号。
参考来源：
OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux
https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html
安全漏洞的响应速度正在成为衡量团队成熟度的关键指标。从 OpenSSH 这次的快速补丁发布来看，开源社区在应对突发安全事件时的协作效率值得关注。如果你对这类安全动态和系统加固话题感兴趣，欢迎在 云栈社区 和更多开发者一起交流。
发表于 前天 18:44
|
查看: 15|
回复: 0
/1 
