OpenSSH曝高危认证绕过漏洞：长密码可登录无密码账户

作者：沙与沫2026.11.06 23:04浏览量：0

简介：某Linux发行版上的OpenSSH服务端被曝严重漏洞：在未启用PAM、开启密码认证的环境中，攻击者输入257至1024字节的超长密码即可绕过校验，直接登录无密码账户。官方已发布补丁版本并建议立即关闭密码认证或禁用SSH服务。本文剖析漏洞成因、触发条件、受影响范围与排查加固方案。

一、漏洞概述：一次“密码对了但没校验”的认证失效

SSH 是服务器运维最基础的入口，其认证逻辑的任何松动都可能直接演变为入侵通道。近日，OpenSSH 项目针对一个可绕过密码校验的高危缺陷发布了紧急修复版本。该漏洞的典型表现是：在特定 Linux 发行版环境下，攻击者无需知道任何真实口令，只要向目标账户输入一段长度介于 257 到 1024 字节之间的密码，就能通过认证，直接登录那些“本来就没有设置密码”的账户。

问题的严重性在于三点：其一，触发门槛低，攻击者只需具备网络可达性和目标账户名；其二，成功率稳定，单次连接即可命中，不存在概率性失败；其三，受影响账户往往是“仅配置密钥登录”的运维账户，这类账户在管理者认知中恰恰是“最安全”的，因而容易被忽视。OpenSSH 官方将该漏洞评级为严重，并同步发布了修复版本；相关发行版也已为受支持的系统版本推送补丁包。

需要强调的是，漏洞并非出在 SSH 协议本身，也不影响绝大多数通用 Linux 环境。它是一次特定 C 语言运行时库与 sshd 认证流程交互时产生的边界处理缺陷，因此受影响范围有明显的环境特征。

二、漏洞成因：musl 环境下的认证路径偏差

OpenSSH 核心开发者 Damien Miller 对该问题的说明指向了根本原因：sshd 与某类精简 C 语言运行时库（musl）之间的交互逻辑存在偏差。要理解这一点，需要先厘清 sshd 的密码校验路径。

在常规配置中，sshd 处理密码认证有两条路径：

  • PAM 路径：将密码交由 PAM（可插拔认证模块）框架校验，由系统认证栈统一处理账户状态、密码哈希、过期策略等；
  • 非 PAM 路径：sshd 直接读取本地账户的密码哈希，自行完成比对。

问题出在第二条路径上。当 sshd 未启用 PAM 支持时，它需要直接判断“该账户是否有可用密码”。在 musl 环境下，相关字符串与缓冲区处理逻辑在遇到超长输入时出现了判断偏差，使得“无密码账户”（密码字段为 * 或类似占位符）被错误地纳入可比对范围，而超长密码输入又恰好绕过了正常的校验分支，最终形成“无需正确口令即可通过”的结果。

这就解释了为什么非 Linux 系统、基于 glibc 的 Linux 系统，以及启用 PAM 校验的系统均不受影响——它们的认证路径或底层库行为不满足该缺陷的触发前提。

三、四条件叠加：风险判定与暴露面分析

该漏洞的触发不是单一条件所致，而是多个配置项叠加的结果。发行版安全公告给出了明确的判定清单，服务器同时满足以下四项时才存在实际风险：

  1. 认证路径不走 PAM：运行的是编译时未启用 PAM 的 sshd 软件包，或虽安装了 PAM 版本但显式配置了 UsePAM no；
  2. 密码认证处于开启状态：PasswordAuthentication 为 yes，而这恰是 OpenSSH 的默认值；
  3. 存在无密码账户：账户密码字段为 *，即未设置可用密码；
  4. 存在使用强哈希的本地账户：至少有一个本地账户的密码哈希以 $5$（SHA-256）或 $6$（SHA-512）开头。

只要设备上存在一个设置了密码的账户，所有无密码账户都会进入暴露状态。攻击者还需掌握一个无密码账户的用户名，即可发起登录。公告明确指出，该攻击单次连接即可 100% 成功。

在实际系统中，无密码账户并不罕见，常见来源包括：

  • 通过 adduser 未设置密码创建的仅密钥登录用户，或用 usermod -p '*' 显式配置的账户；
  • 通过目录服务同步、没有本地 shadow 条目的用户；
  • 部分基础镜像中默认配置为 root:* 的 root 账户；
  • 云镜像中预置的默认运维用户。

root 账户通常受 PermitRootLogin prohibit-password 默认配置保护，只有管理员显式改为 yes 时才允许直接登录。但这一层保护存在旁路：若某个可被攻击的无密码账户能通过 doas、sudo 等方式提权至 root，则 root 的登录限制便形同虚设。因此，评估风险时不能只看 root 配置，还要梳理普通账户的提权路径。

四、排查方法：用命令确认自身是否在风险区

面对这类“配置叠加型”漏洞，最有效的做法是逐条核验四个条件。以下命令可作为排查起点：

  1. # 1. 确认 sshd 是否启用 PAM，以及密码认证是否开启
  2. sshd -T | grep -E '^(usepam|passwordauthentication|permitrootlogin)'
  4. # 2. 查看 sshd 二进制是否链接了 PAM 库
  5. ldd "$(command -v sshd)" | grep -i pam
  7. # 3. 列出密码字段为 * 或空的账户（无密码账户）
  8. awk -F: '($2 == "*" || $2 == "") {print $1}' /etc/shadow
  10. # 4. 检查是否存在 $5$ / $6$ 哈希的账户
  11. awk -F: '($2 ~ /^\$[56]\$/) {print $1}' /etc/shadow
  13. # 5. 核查可提权路径
  14. cat /etc/doas.conf 2>/dev/null

判读逻辑很直接：若第 1 步输出 usepam no 或二进制未链接 PAM，且 passwordauthentication yes，同时第 3 步有输出、第 4 步也有输出，则系统处于暴露状态，应立即处置。

对于批量环境，建议将上述检查脚本化，通过配置管理或巡检系统定期执行，并把“无密码账户清单”和“sshd 认证配置”纳入基线管理，而不是等到漏洞披露才临时排查。

五、加固方案：从临时缓解到彻底修复

处置思路分为“立即缓解”和“彻底修复”两层。

临时缓解（分钟级生效）

最直接的手段是关闭密码认证，强制使用密钥登录：

  1. # 在 sshd_config 中设置
  2. PasswordAuthentication no

或在受影响的系统上直接停用 SSH 服务，待补丁就绪后再恢复。前者更适合仍需远程运维的场景，后者适用于可短暂中断访问的资产。修改后务必重载服务并复核生效配置：

  1. sshd -t && systemctl reload sshd
  2. sshd -T | grep passwordauthentication

对于确实需要保留密码认证的环境，可退而求其次：为所有无密码账户补设强密码，或将其密码字段改为不可登录的锁定状态，从条件三、条件四上切断触发链。同时应审计 doas/sudo 配置，收敛无密码账户的提权能力。

彻底修复（版本升级）

根本解决依赖官方补丁。OpenSSH 已发布修复版本封堵该缺陷，相关发行版也为受支持的系统版本提供了修复包。升级后应确认 sshd 版本与包管理器记录一致，并重启服务：

  1. # 以系统包管理器为准执行升级
  2. # 升级完成后核对版本并重启
  3. sshd -V
  4. systemctl restart sshd

需要注意，升级只消除漏洞本身，不改变“密码认证开启 + 无密码账户存在”这一风险组合。因此升级后仍建议按最小权限原则收紧认证配置：默认关闭密码认证、限制可登录账户范围、对管理入口做网络层访问控制。

六、最佳实践与长期建议

这起漏洞为基础设施安全提供了几个值得沉淀的教训：

第一，默认配置不等于安全配置。 密码认证默认开启、基础镜像默认创建无密码运维账户，这些便利性设计在特定运行时环境下会组合成攻击面。生产环境应显式声明认证策略，而非依赖默认值。

第二，认证链路要“单一且明确”。 要么统一走 PAM 由系统认证栈集中管控，要么明确使用非 PAM 路径并承担相应审计责任。混用与隐式回退是缺陷滋生的温床。

第三，把“无密码账户”当作资产管理。 仅密钥登录的账户应定期盘点，确认其确实无法通过密码路径登录；云镜像预置账户应在首次启动时完成收敛。

第四，建立漏洞响应的配置核查能力。 本次漏洞的判定条件是四项配置的组合，这提示我们：漏洞管理不能只看“版本是否受影响”，还要能快速回答“我的配置是否满足触发条件”。将配置基线、账户清单与版本信息联动起来，才能把响应时间从小时级压缩到分钟级。

第五，网络层兜底不可省略。 无论认证逻辑如何演进，对 SSH 入口做来源限制、堡垒机收敛与异常登录告警，始终是最后一道有效防线。认证绕过类漏洞的最大威胁在于“静默成功”，而网络层与行为层的监控能在认证之后发现异常。

截至目前，尚未发现该漏洞被实际利用的公开报告，但这不构成放松处置的理由。对于同时满足四项条件的系统，建议按“先缓解、再修复、后审计”的顺序完成闭环：立即关闭密码认证或停用服务，尽快升级到修复版本，随后复查账户与提权配置，确保风险组合被真正拆解，而不是仅仅被版本号掩盖。

最热文章