Alpine Linux 修复 OpenSSH 服务端密码认证绕过漏洞

如果你在 Alpine Linux 上运行 sshd，请立即更新 openssh 并重启 sshd。 仅升级软件包并不会替换正在运行的守护进程。 如果暂时无法更新，至少应禁用密码登录：在 sshd 配置中设置 PasswordAuthentication no，然后重启 sshd。 这两种做法都能堵住漏洞。 能够访问你 SSH 端口的攻击者，无需知道任何密码即可登录。只需一次连接，每次都能成功，且无需重试。 攻击者需要知道一个密码字段为 * 的账户名（即未设置密码的账户，这对仅使用密钥登录的账户来说很常见），并且 目标机器上至少还要有另一个使用 $5$ 或 $6$ 密码哈希的账户。然后攻击者发送一个非常长的密码（257 到 1024 字节）。只要有一个用户设置了密码就足够了：它会让所有未设置密码的账户都变得可被登录。 详情见 OpenSSH 10.6p2 发布 说明。撰写本文时，尚未分配 CVE 编号。 如果以下所有条件均成立，则你受到影响： 受影响的版本：我们检查过的所有 Alpine 版本，3.21 到 3.24 以及 edge，还有不再接收定期更新的旧版本（3.16 到 3.20）。 apk upgrade -U -a Alpine 3.21.10、3.22.8、3.23.8 和 3.24.4 包含修复后的软件包（见 发布公告）。 修复后的软件包版本为： 升级后请重启 sshd（rc-service sshd restart）。升级软件包 不会重启正在运行的 sshd，因此必须在升级后手动执行。 开始之前，请确保你的 SSH 密钥登录可用，并保持当前 会话打开，直到你测试过新的登录。 请以 root 身份运行以下命令。前两条命令会创建一个 drop-in 文件。Alpine 的 默认 sshd_config 从 3.19 起会读取该目录；更早的版本 会忽略它。sed 命令会将 /etc/ssh/sshd_config 中每一行 PasswordAuthentication 的 yes 改为 no，无论间距如何， 包括 Match 块内的行。它还会在文件顶部添加 PasswordAuthentication no， 以应对原本没有该行的情况，并将原文件保存为 /etc/ssh/sshd_config.bak。最后两条命令会检查 配置、重启守护进程并显示结果： mkdir -p /etc/ssh/sshd_config.d echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf sed -i.bak -e '1i PasswordAuthentication no'
-e 's/^(\sPasswordAuthentication[^y#])yes/\1no/i'
/etc/ssh/sshd_config sshd -t && rc-service sshd restart sshd -T | grep -i passwordauthentication 最后一条命令应输出 passwordauthentication no。要撤销更改，请删除 /etc/ssh/sshd_config.d/00-no-passwords.conf，并将 /etc/ssh/sshd_config.bak 复制回 /etc/ssh/sshd_config。 官方 tiny-cloud 镜像（qcow2、VHD 和 AMI 制品）从 3.18.11 到 3.24.3 版本都附带一个密码字段为 * 且 doas 无需密码的 alpine 用户。它们在首次启动时是安全的。一旦机器上存在任何 $6$ 哈希，它们就会变得可利用， 例如管理员设置了控制台密码，或 user-data 添加了带 hashed_passwd 的用户。此时攻击者 就能以 alpine 身份获得 shell，并可通过 doas 提权为 root。 从 3.21.10、3.22.8、3.23.8、3.24.4 及更高版本构建的镜像包含修复后的 软件包。更早的小版本镜像则不包含，因此在每个正在运行的 实例上，请更新 openssh 或禁用密码认证。 这些版本存在同样的缺陷。3.21 已于 2026-11-01 结束支持，但我们已为每个版本发布修复后的软件包，一直回溯到 3.16。 请在 /var/log/messages 中查找 sshd 日志行，内容为 Accepted password for 一个没有密码的账户（alpine、root 或任何仅使用密钥的用户）。 审查暴露机器上的 doas 使用情况以及最近创建的用户、文件和 authorized keys。如果 无法排除某次登录，请将该机器视为已失陷。 当 sshd 在未启用 PAM 的情况下构建时，它通过用 crypt()（将密码转换为存储哈希的 C 库函数）对尝试的密码进行哈希，并将结果与存储的密码字段比较来校验密码。对于存储字段太短而无法包含 salt（哈希的随机前缀）的账户，sshd 会借用另一个账户的 salt。 当密钥长度超过 256 字节时，musl 的 crypt() 会返回字符串 * 作为错误指示。而 * 也正是每个没有密码的账户所存储字段的内容，因此“哈希”匹配，登录成功。 OpenSSH 10.6p2 在 sshd 中避免了该问题。上述稳定分支软件包 包含针对同一问题的补丁。 由 Wakefield 的 Özgün Kültekin 报告。感谢 OpenSSH 项目的 Damien Miller 和 Darren Tucker 提供修复及 10.6p2 版本，感谢 Timo Teräs 协助分析该问题，感谢 Natanael Copa 构建并上传了更新后的软件包。