OpenSSH 认证绕过漏洞（CVE-2026-123158）排查与修复：核对 musl 环境、认证配置及升级结果

CVE-2026-123158 公开后，最需要避免的判断方式，是把“linux 服务器”整体划进受影响范围。按照 NVD 的记录，这个漏洞成立需要同时满足几个条件：运行 OpenSSH 10.6p2 之前的版本、使用 musl libc、未启用 PAM，并且账户配置落在特定组合里。缺少任何一个条件，就不能仅凭操作系统类型下结论。对运维和安全团队来说，处置顺序应当是先核验条件，再决定是否升级、如何验证、何时回滚，而不是先批量重启 sshd。

漏洞成立的条件链

公开资料对触发机制的描述基本一致：musl 的 crypt() 在哈希失败时返回 "*"，而 OpenSSH 的 SHA512 密码处理路径对超长输入设有长度上限，超过上限的密码会走到这个返回值上。当 /etc/shadow 中某些账户的密码字段本身就是 "*" 或类似占位符时，比较结果会被误判为匹配，认证因此被放行。NVD 将该问题归类为 CWE-394（意外状态码或返回值），并写明在满足条件时，长度在 256 到 1024 字符之间的任意密码都可能成功。腾讯云的安全通告则从另一侧描述了影响：攻击者可向本应禁止密码登录的账户提交超长密码，从而获得系统访问权限。

这意味着四类条件需要同时成立：

• 版本：sshd 低于 10.6p2，且没有安装发行版回移的修补包；
• libc：系统实际使用 musl，而不是 glibc；
• PAM：sshd 未启用 PAM 认证路径；
• 账户与暴露面：存在无密码、锁定或仅允许密钥登录的账户，且 sshd 可从不可信网络到达。

需要说明的是，不同来源对账户条件的细节表述略有差异。NVD 的措辞是“某些账户配置”，腾讯云通告提到还需要环境中存在另一个拥有真实密码哈希的账户用于借用 salt，第三方分析则多举 Alpine linux 上的锁定账户为例。这些差异不影响处置思路，但提醒我们：不要用单一博客的复现描述去推断自己的主机一定可利用，也不要用“我们用的是强密码”来安慰自己。这不是密码强度问题，而是认证判定逻辑问题，强密码策略不构成缓解措施。

第一步：按 libc 与 PAM 给资产分组

排查应从“这台机器到底运行着什么”开始，而不是从资产表里的发行版名称开始。容器镜像、嵌入式设备和定制固件经常与宿主机的发行版标签不一致。

Alpine Linux 是公开资料中最常被点名的平台，OpenWrt、Buildroot、Yocto 以及大量基于 Alpine 的容器镜像也在讨论范围内。反过来，TencentOS、RHEL、Ubuntu、Debian、CentOS、Rocky、AlmaLinux 等主流镜像默认使用 glibc 加 PAM，腾讯云通告明确将其列为默认不受影响。这个对照很有用，但它只适用于“默认配置”：如果有人在 glibc 系统上编译了不带 PAM 的 sshd，或者把 Alpine 的二进制搬进了别的根文件系统，发行版标签就不能作为判断依据。

还需要注意变体包的问题。部分发行版会提供启用 PAM 的独立 sshd 包，安装哪一个、二进制链接了哪些库，都要以实际安装结果为准。容器场景同理：如果镜像里根本没有安装 openssh-server，它就不构成 sshd 暴露面；如果安装了，就要按同一套条件核验，而不是因为“它是容器”就跳过。

第二步：确认暴露面与账户条件

条件筛选之后，剩下的是“这台主机是否真的能被利用”。这一步不需要复现攻击，只需要回答几个运维问题：

• sshd 监听在哪些地址上，安全组或防火墙是否允许来自办公网、互联网或不可信合作方的连接；
• 是否存在仅密钥登录的账户、被锁定的账户、无密码账户，以及是否允许 root 登录；
• PasswordAuthentication、AuthenticationMethods、PermitRootLogin 的实际生效值是什么；
• 是否有跳板机、堡垒机或 VPN 作为前置访问控制，sshd 是否只对受控网段开放。

这里要克制一种冲动：不要为了“确认能不能打进去”而在生产环境用真实账户尝试超长密码。授权验证应放在与生产隔离的测试环境，使用专门的测试账户和测试主机，并保留操作记录。生产环境只需要做配置与暴露面核验，就足以支撑补丁优先级判断。

对于仍在使用 musl 且未启用 PAM 的主机，如果 sshd 对不可信网络开放，同时存在仅密钥或锁定账户，应视为高优先级处置对象。反之，如果 sshd 只监听在带外管理网段、前面有强认证的堡垒机，风险等级可以下调，但不应因此长期不修，因为访问控制边界本身也可能变化。

第三步：升级到修复版本并让它真正生效

公开资料给出的修复版本是 OpenSSH 10.6p2，于 2026 年 11 月 5 日发布；Alpine 各受支持分支也已提供修补包。修复提交为 4353fdc43，据第三方分析可以干净地回移到 7.3p1 及之后的版本。这意味着处置路径不止一条：优先使用发行版提供的回移包，其次才是自行编译上游版本。

变更前的准备应按“可能失联”来设计，而不是按“应该顺利”来设计：

1. 确认带外管理通道可用，例如云控制台 VNC、IPMI、串口或独立的管理网段；
2. 备份 sshd_config、PAM 相关配置、主机密钥和当前安装包版本信息；
3. 准备可恢复的快照或旧版本安装包，明确回滚命令；
4. 安排维护窗口并通知相关方，避免在业务高峰执行；
5. 升级时保留至少一个已建立的 SSH 会话不关闭，作为配置错误时的退路。

以 Alpine 为例，常规做法是更新软件源后升级 openssh 相关包；如果使用源码编译，则需要在编译后确认 sshd_config 路径、PAM 支持选项和安装位置与旧版本一致。升级完成后必须重启 sshd，因为只更新软件包不会替换已经在运行的守护进程。这一点在容器场景尤其容易被忽略：在运行中的容器里执行包升级，既不会持久化，也不会替换容器主进程；正确做法是重建镜像并重新部署。

第四步：验证版本、配置与认证行为

升级完成不等于处置完成。验证应覆盖三个层面，并且留下可复核的记录。

版本与进程层面：确认 sshd -V 或包管理器显示的版本不低于修复版本，确认 /proc/<pid>/exe 指向新二进制，确认监听端口与升级前一致。如果使用发行版回移包，版本号可能不显示为 10.6p2，此时应以发行版公告中的修复版本号和包版本为准，而不是只看上游版本字符串。

配置层面：用 sshd -T 检查 usepam、passwordauthentication、permitrootlogin 等生效值，确认升级没有覆盖或重置配置。Alpine 上还需要确认实际安装的是否为预期的 sshd 变体包。

认证行为层面：在隔离测试环境中，用测试账户验证三件事——正常的密钥登录仍然可用；启用了 PAM 密码认证的账户仍能正常登录；对无密码或仅密钥账户提交超长密码应当失败。第三条是本次修复的核心行为，但只应在授权测试环境执行，并记录测试账户、源地址、时间与结果。

日志是验证的一部分。Alpine 上可查看 /var/log/messages 或通过 journalctl 过滤 sshd，Debian/Ubuntu 系通常在 /var/log/auth.log。重点看升级后是否出现异常的 Accepted password，尤其是那些本应只允许密钥登录的账户。

第五步：监控异常登录与准备回滚

公开分析普遍指出，目前没有针对该漏洞的专用 IOC，也没有确认的攻击者 IP 或域名清单。这使得行为监控比特征匹配更重要。可关注的信号包括：

• 仅密钥登录账户出现密码认证成功的记录；
• 同一源地址在多次失败后突然成功，或失败次数的分布明显异常；
• 非工作时段、非常用地理位置的 SSH 会话；
• 登录后短时间内出现提权、创建账户、修改 authorized_keys、下载工具等动作；
• 容器或嵌入式设备上出现不该存在的交互式会话。

这些信号本身不是漏洞证据，但可以作为排查入口。把它们接入现有的 SIEM 或日志告警，比临时写一条 grep 更可持续。

回滚方案需要在升级前就写好。保留旧版本安装包或快照，明确回滚后同样要重启 sshd，并评估回滚窗口内主机重新暴露的风险。如果升级后出现认证异常，优先恢复配置而不是立即回滚二进制；如果确认是新版本兼容性问题，再按预案回退，并在回退后限制 sshd 的暴露面，直到问题解决。

把条件核验变成长期资产

这次漏洞值得留下的不只是补丁记录，还有资产属性的补全。很多团队的主机台账只记录发行版和版本号，却在这次排查中被迫临时登录每台机器确认 libc 和 PAM。更稳妥的做法是把“libc 类型”“sshd 是否启用 PAM”“sshd 实际版本与包来源”变成资产清单的常规字段，把容器基础镜像的 OpenSSH 版本纳入构建基线，把 Alpine、OpenWrt、Yocto 这类 musl 环境单独打标。

回到最初的判断原则：CVE-2026-123158 影响的是特定组合，而不是所有 Linux。先确认 musl 与 PAM，再判断版本和暴露面，最后才决定补丁节奏与验证深度。这样既不会漏掉真正需要处置的主机，也不会因为一个发行版标签就把大量默认不受影响的系统卷进不必要的变更。