OpenSSH 高危认证绕过漏洞：成因、判定与修复实践

一、事件背景与风险概述

SSH 作为服务器远程运维的基石协议，其认证链路的任何缺陷都可能直接演变为入侵入口。近期，OpenSSH 项目发布紧急安全更新，修复了一个被评为”严重”级别的认证绕过漏洞。该漏洞的特殊之处在于：它并非存在于 OpenSSH 主线的通用代码路径中，而是在特定 C 语言运行时库与 OpenSSH 服务端的交互边界上被触发——只有在使用某类精简运行时库（musl）的 Linux 发行版上，且编译期未启用 PAM 支持的场景下，攻击者才能利用超长密码绕过认证，直接登录无密码账户。

从攻击者视角看，这个漏洞的门槛低得惊人：只需具备服务器网络可达性、掌握目标账户名，并构造长度在 257 到 1024 字节之间的密码字符串，即可在单次连接中完成登录，成功率接近 100%。这意味着，任何暴露在公网、且满足触发条件的 SSH 服务，都可能在毫无告警的情况下被静默突破。

本文将从漏洞机理、触发条件、受影响判定、紧急缓解与长期修复五个维度展开，帮助运维与开发人员建立完整的处置框架。

二、漏洞成因：认证校验链路上的”短路”

要理解这个漏洞，需要先厘清 SSH 密码认证的常规流程。当客户端提交用户名与密码时，服务端（sshd）通常有两种密码校验路径：

1. PAM 路径：将凭据交给可插拔认证模块（PAM）框架，由系统级的认证策略完成校验；
2. 本地密码哈希路径：直接读取账户的影子密码条目（shadow entry），调用运行时库提供的密码哈希校验函数进行比对。

问题出在第二条路径上。在基于 musl 运行时库的环境中，当密码输入长度超过常规边界（257 字节以上）时，哈希校验函数的返回值与错误处理逻辑出现了语义偏差：校验失败本应返回明确的”不匹配”信号，但在超长输入场景下，该信号被错误地解释为”校验通过”或”无需校验”。对于密码字段被标记为 *（即未设置密码、仅允许密钥登录）的账户，这一偏差直接导致认证被绕过——服务端认为凭据合法，从而放行会话。

OpenSSH 项目维护者在分析中指出，该缺陷的本质是 sshd 与底层 C 语言库之间的交互逻辑问题，而非 OpenSSH 自身认证逻辑的设计错误。这也解释了为何影响范围呈现明显的”环境相关性”：

• 不受影响：非 Linux 系统、基于 glibc 的 Linux 系统、以及通过 PAM 完成密码校验的部署；
• 受影响：编译时未启用 PAM、且运行于 musl 环境的 sshd 部署。

需要强调的是，漏洞利用不依赖任何复杂的中间人条件或凭据窃取，属于典型的”配置叠加型”高危缺陷——单个配置项看似无害，组合起来却打开了认证后门。

三、四条件风险模型：何时真正暴露

判断一台服务器是否处于风险之中，不能只看单一配置。安全公告给出的判定框架是”四条件同时满足”，缺一不可：

条件一：sshd 未经 PAM 校验密码。
即服务端编译时未启用 PAM 支持，或虽安装了 PAM 版本但显式配置了 UsePAM no。在部分精简发行版中，默认的服务端软件包在编译期就关闭了 PAM，这是风险的起点。

条件二：密码登录处于开启状态。
PasswordAuthentication 保持默认值 yes。这是多数发行版的出厂配置，也是攻击能够发起的前提。

条件三：存在未设置密码的账户。
即影子密码字段为 * 的账户。这类账户通常包括：创建时未设置密码的仅密钥登录用户、通过命令显式将密码字段置为 * 的用户、从目录服务同步而来且缺少影子条目的用户，以及基础镜像中默认以 root:* 形式存在的超级用户。

条件四：至少有一个本地账户的密码哈希以 $5$ 或 $6$ 开头。
即系统中存在使用 SHA-256 或 SHA-512 算法存储密码的账户。这一条件看似无关，实则是触发哈希校验函数进入缺陷分支的必要”土壤”——只有当校验逻辑被实际调用，边界缺陷才会显现。

四条件叠加后，攻击面就形成了：设备上只要存在一个设置了密码的账户，所有无密码账户都会暴露在风险之下。攻击者无需知道那个”有密码账户”的任何信息，它只是让校验路径被激活的”引信”。

四、受影响环境的具体画像

结合上述模型，可以勾勒出高风险环境的典型特征：

• 默认编译策略：服务端软件包在构建时未链接 PAM，密码校验走本地哈希路径；
• 默认登录策略：密码认证开启，未做显式关闭；
• 账户形态：基础镜像的 root 账户以 root:* 形式存在；通过自动化工具创建的密钥专用账户未设置密码；云镜像中预置的默认用户同样可能无密码；
• 哈希形态：系统中至少一个账户使用 SHA-256/SHA-512 存储密码。

值得单独讨论的是 root 账户的保护边界。默认配置下，root 的直接登录受 PermitRootLogin prohibit-password 约束，攻击者无法直接用超长密码登录 root。但这层保护并非牢不可破：如果被攻破的无密码账户具备通过权限提升工具（如 doas 等）获得 root 权限的能力，那么这层限制就形同虚设。换言之，无密码账户的沦陷本身就是提权的跳板，不能因为 root 受保护就放松警惕。

此外，部分云镜像中预置的默认用户同样属于无密码账户范畴，这类账户往往被自动化配置管理工具使用，日常容易被忽视，却在漏洞场景下成为最直接的入口。

五、紧急缓解：分钟级的止血措施

在补丁全面铺开之前，或在无法立即升级的遗留系统中，应优先执行以下缓解动作。核心思路是切断触发链路中的任意一环，因为四条件是”与”关系，破坏其一即可让攻击失效。

措施一：关闭密码认证。
在服务端配置中设置：

PasswordAuthentication no

这一项直接破坏条件二，是最快、副作用最小的止血手段。对于已经完全采用密钥登录的团队，这应当是常态化配置而非临时措施。

措施二：禁用或限制 SSH 服务暴露面。
对于确实无法调整认证策略的系统，可临时停止 SSH 服务，或通过防火墙/安全组将 22 端口的访问源收敛到可信管理网段。攻击者需要网络可达性，收敛暴露面等于抬高了利用门槛。

措施三：清理无密码账户。
排查影子密码字段为 * 的账户，确认其存在必要性。对不再使用的账户及时锁定或删除；对必须保留的密钥专用账户，评估其是否真的需要保留在 SSH 可登录范围内。

措施四：启用 PAM 校验路径。
在条件允许时，改用带 PAM 支持的服务端构建并配置 UsePAM yes，使密码校验回归系统级认证框架，从根上绕开缺陷分支。

需要提醒的是，缓解措施只是争取时间，不能替代补丁。上述配置变更应纳入变更管理记录，并在升级完成后重新评估是否保留。

六、长期修复：升级与验证

官方已在最新补丁版本中封堵该漏洞，相关发行版也为受支持的版本线发布了修复包。修复路径建议按以下顺序推进：

1. 资产盘点：梳理所有运行相关发行版的服务器，标注其运行库类型、PAM 编译状态、密码认证配置与账户形态；
2. 分批升级：优先处理公网暴露、且满足四条件的高风险节点；升级服务端软件包至含修复的版本；
3. 重启生效：升级后确认服务进程已重启，新二进制已加载；
4. 回归验证：升级完成后，重新核查 PasswordAuthentication、UsePAM 等关键配置是否符合预期，避免升级过程覆盖自定义配置；
5. 持续监控：在认证日志中关注异常的长密码尝试、短时间内的高频失败登录，以及无密码账户的登录记录。

一个容易被忽略的环节是配置漂移。自动化配置管理工具可能在升级后将配置回滚到模板默认值，使 PasswordAuthentication 重新变为 yes。因此，修复后应将安全基线固化为配置项，而非依赖人工记忆。

七、加固建议与最佳实践

从这次漏洞可以提炼出若干具有普适性的 SSH 加固原则：

• 最小化认证面：除非业务确有必要，一律关闭密码认证，全面采用密钥并配合口令保护；
• 避免”裸奔”账户：任何允许 SSH 登录的账户都应有明确的凭据策略，无密码账户应限定登录来源或直接禁止登录；
• 收敛暴露面：SSH 端口不应对公网全开，管理入口应通过跳板机、专线或安全组白名单控制；
• 保持补丁节奏：订阅发行版与上游项目的安全公告，建立高危漏洞的快速响应流程；
• 配置即代码：将 UsePAM、PasswordAuthentication、PermitRootLogin 等关键项纳入版本化配置与自动化校验，防止漂移；
• 日志与告警：对认证失败率、异常密码长度、非工作时段登录等维度建立告警规则，让”静默突破”无处藏身。

八、小结

这个漏洞的警示意义在于：安全风险往往不来自某个单点的”大缺陷”，而来自多个”看起来没问题”的默认配置叠加。未启用 PAM 是编译策略，密码登录开启是出厂默认，无密码账户是运维习惯，哈希算法是历史选择——四者单独看都合情合理，组合起来却构成了可被单次连接 100% 利用的认证绕过。

对运维团队而言，当务之急是按四条件模型完成自查，对命中项立即执行缓解，并尽快升级到修复版本。对更广泛的开发者而言，这次事件再次说明：认证链路上的每一个边界条件都值得被认真对待，尤其是在跨运行时库、跨认证框架的交互地带，测试覆盖与边界验证不能留白。