强密码挡不住认证逻辑漏洞

看到 CVE-2026-123158 的通报，我第一反应也是“又是老生常谈的密码问题”——直到我认真读完了漏洞链路。这次真不是密码太弱，而是 sshd 的认证逻辑被玩坏了。简单说：在特定条件下，你给一个只允许密钥登录、早就被锁定的账户，随手敲一串几百个字符的超长密码，它可能直接放你进去。强密码策略？在这个漏洞面前毫无意义。

这个 CVE 成立需要好几个条件同时踩中：sshd 版本低于 10.6p2、系统用的是 musl libc 而不是 glibc、sshd 没启用 PAM，再加上账户配置上有“可乘之机”。这里面的链条是：musl 的 crypt() 在哈希失败时返回一个特殊占位符，而 OpenSSH 的 SHA512 处理路径对超长输入设有长度上限，一旦超过就撞上这个返回值；如果 /etc/shadow 里某些账户的密码字段本身就是那个占位符，比较结果就会被误判为匹配。NVD 给它的分类是“意外状态码或返回值”，说白了就是认证环节的返回值撒谎了。

让我觉得最值得吐槽的是排查思路。很多人一看“linux 服务器”四个字，要么立刻全量重启 sshd，要么安慰自己“我们密码策略很严格，没事”。都不对。正确的第一步是按 libc 和 PAM 给资产打标——用 ldd --version 看 libc 类型，用 ldd /usr/sbin/sshd | grep -i pam 看二进制是否链接了 PAM，用 sshd -T 看配置里的 PAM 开关，再用 readlink -f /proc/$(pidof sshd)/exe 确认跑着的到底是哪个二进制，防止“包升级了、进程还是旧的”这种乌龙。Alpine 这类 musl 环境要重点留意，但别光看发行版标签——有人在 glibc 系统上编译了不带 PAM 的 sshd，或者把 Alpine 的二进制搬进别的根文件系统，标签就不作数了。

修复版本是 OpenSSH 10.6p2，2026 年 11 月 5 日发布，Alpine 各分支也出了修补包。但我最想提醒的是：升级完一定要重启 sshd，只更新软件包不会换掉已经在跑的守护进程。容器里尤其容易翻车——在运行中的容器里升级包既不持久化也不替换主进程，正确姿势是重建镜像重新部署。验证的时候在隔离测试环境用测试账户试着提交超长密码，确认它按预期被拒，顺便翻翻日志里有没有那种本应只允许密钥登录的账户突然出现密码认证成功的记录。

说到底，这个漏洞教给我一件事：别再用“密码够不够强”来评估认证安全了，先把逻辑条件核清楚，比什么都强。