CVE-2026-123158：Alpine 上的 OpenSSH 密码绕过，升级后记得重启 sshd

CVE-2026-123158（发现者给它起名 sshole，CVSS 8.1）影响 Linux 上使用 musl libc 且关闭 PAM 的 sshd：对着密码字段为 * 的账号，发一个 257～1024 字节的超长密码，密码认证就被绕过。glibc 系统（Debian、Ubuntu、Fedora）不受影响。

修复版本是 OpenSSH 10.6p2（2026-11-05 发布）。Alpine 用户升级后必须重启 sshd，否则跑着的还是旧进程。

一、影响范围

二、四个条件同时满足才中招

• libc 是 musl：Alpine、OpenWrt、Buildroot、Yocto、部分 Docker 镜像；
• sshd 关闭 PAM：Alpine 的 openssh-server 默认如此，或者手工设了 UsePAM no；
• 密码登录开着：默认就是开的；
• 存在密码字段为 * 的账号：只允许密钥登录的用户、被锁定的 root、部分 LDAP 用户（Alpine 3.16 起 root 用 *）。

另外还需要有一个「有真实密码」的账号存在：sshd 为防时序探测（CVE-2016-6210 的补丁）会借用该账号的盐值来计算哈希，这一步把问题暴露出来。

三、为什么会这样

• shadow 里密码字段写 *，表示「此账号不接受密码登录」，正常情况下任何密码都匹配不上；
• musl 的 crypt() 失败时不返回 NULL，而是返回一个字符——2012 年的改动选的就是 *；
• musl 同一年给 sha512crypt 加了 256 字节上限（KEY_MAX），超长密码直接判为失败，于是返回 *。

三者叠加：sshd 拿 * 和 shadow 里的 * 做比较，strcmp 判定相等 → 认证通过。发现者称这个问题从 2016 年就存在，直到 2026 年才被系统性测出来。

四、修复：升级 + 重启 + 验证

• 升级：apk update，然后 apk upgrade（或只升 openssh）；
• 重启 sshd：rc-service sshd restart——最容易漏的一步，包升级不会重启运行中的服务；
• 验证：ssh -V，显示 OpenSSH_10.6p2 或更高才算完成。

暂时无法升级的临时措施：把 PasswordAuthentication no 写进 /etc/ssh/sshd_config.d/ 下的配置文件，然后重启 sshd。

五、要不要怀疑已经被利用

这个洞的特征是「本该拒绝的密码被接受」，所以日志里会出现密码登录成功的记录，而对应账号本不该有密码（只允许密钥登录的账号、root 等）。可以查 /var/log/auth.log、/var/log/messages 或 journalctl -u sshd。

如果该账号还带免密 doas / sudo（Alpine 官方 AWS、Azure 镜像的默认 alpine 用户就是），那就不只是普通账号，而是直接 root，建议按已失陷处理：轮换密钥、排查持久化、重启相关服务。

六、常见误区

• 「装的是 Alpine 就一定中」——不一定，还要看 PAM、密码登录、* 账号三个条件；
• 「升级完就好了」——不重启 sshd 等于没修；
• 「glibc 也受影响」——不受影响；
• 「只有服务器要管」——基于 musl 的 Docker 镜像、OpenWrt 路由器、Buildroot/Yocto 构建同样要查。

七、来源

• OpenSSH 官方 release notes（Portable OpenSSH 10.6p2，2026-11-05）：musl + 关闭 PAM 的 Linux 存在密码认证绕过，已修复，报告者 Özgün Kültekin（wakefield.co）；
• sshhole.com（发现者技术说明）：crypt() 返回 *、256 字节上限、CVE-2016-6210 的盐值借用、影响账号类型、自查与修复方法；
• CVE-2026-123158：Ubuntu 安全页、CERT-In CIVN-2026-0542、BSI 2026-306241（CVSS 8.1，影响 OpenSSH < 10.6p2）；
• 国内编号 QVD-2026-104595 的安全公告。