SSH 服务长密码校验绕过漏洞的应急修复与防护指南

一、事件背景：一次被评级为“严重”的紧急补丁

近期，主流 SSH 服务端实现发布了一个紧急安全补丁，用于封堵一个可导致身份认证被绕过的严重漏洞。该漏洞的特殊之处在于：它并非协议设计缺陷，也不是常见的配置疏漏，而是服务端程序与某类精简发行版所采用的底层 C 标准库之间交互逻辑不一致所引发的边界问题。

在特定条件下，攻击者只需具备目标服务器的网络可达性、知道一个存在的账户名，并提交一段长度介于 257 到 1024 字节之间的密码字符串，即可完成登录——而无需知道该账户的真实密码。更值得警惕的是，被登录的往往是那些“本不应支持密码登录”的账户，例如仅配置了密钥认证、密码字段为空或为占位符的账户。

这类问题一旦被利用，等同于在堡垒机、跳板机或公网暴露的运维入口上开了一道后门。因此，服务端实现方将其评级为严重，并建议用户立即处置。

二、漏洞成因：为什么会“输错密码也能进”

要理解这个漏洞，需要先厘清身份认证的判定链路。

在常规流程中，SSH 服务端接收客户端提交的凭据后，会经过以下环节：

1. 判断该账户是否允许密码认证；
2. 将提交的密码与系统中存储的密码散列进行比对；
3. 根据比对结果决定是否放行。

问题出在第 2 步的底层实现上。当服务端在编译时未启用可插拔认证模块支持，且直接依赖底层 C 库完成密码校验时，会调用该库提供的密码验证函数。在多数主流 C 库中，该函数对超长输入有截断或拒绝行为，能与服务端预期保持一致；而某类精简发行版默认使用的轻量级 C 库，在实现细节上存在差异，导致超长密码的比对结果出现非预期行为。

具体表现是：当输入密码长度超过 256 字节、进入 257 至 1024 字节区间时，校验逻辑可能返回“通过”，从而绕过真实密码校验。这并非密码被破解，而是校验函数在边界条件下给出了错误结论。

服务端项目维护者已确认，该问题仅影响使用该轻量级 C 库的 Linux 发行版环境；非 Linux 系统、使用主流 C 库的 Linux 系统，以及通过可插拔认证模块校验密码的部署方式，均不受影响。

三、触发条件：四类条件必须同时满足

漏洞的暴露并非无条件，而是需要以下条件同时成立：

序号	条件	说明
1	服务端未通过可插拔认证模块校验密码	编译时未启用相关支持，或显式配置为不启用
2	密码认证处于开启状态	该选项在默认配置中通常为开启
3	系统中至少存在一个设置了密码的账户	包括密码字段为占位符、实际未设置可用密码的账户
4	运行环境使用上述轻量级 C 库	常见于某些追求精简体积的发行版

四者缺一不可。也就是说，如果你的服务端启用了可插拔认证模块，或者显式关闭了密码认证，或者系统不使用该类 C 库，则不会被该漏洞影响。但反过来说，同时满足这四项的服务器，就处于可直接被绕过的风险之中。

原始安全公告还额外列出了一种配置变体：即便安装了带可插拔认证模块支持的软件包，但若配置中显式将该支持关闭，同样会落入受影响范围。

四、紧急处置：三步降低暴露面

在官方补丁全面铺开之前，或对于暂无法立即升级的系统，建议按以下优先级处置。

4.1 第一步：关闭密码认证

这是最直接、最有效的缓解措施。编辑服务端配置文件，将密码认证选项设为关闭：

# /etc/ssh/sshd_config
PasswordAuthentication no

修改后重载服务：

sudo systemctl reload sshd

对于仅依赖密钥认证的运维体系，这一改动几乎无副作用，反而符合最小权限与零信任的最佳实践。

4.2 第二步：如无必要，直接停用服务

对于不提供远程登录能力的设备，或可通过其他受控通道管理的资产，可临时停止并禁用服务：

sudo systemctl stop sshd
sudo systemctl disable sshd

需要强调的是，这一操作会切断现有远程连接，执行前务必确认本地控制台或带外管理通道可用。

4.3 第三步：升级到已修复版本

服务端项目已发布修复版本，相关发行版也为各稳定分支推送了修复包。升级时需注意：

• 确认所安装的服务端软件包已更新到修复版本；
• 若使用带可插拔认证模块支持的变体包，同样需要确认该包已包含修复；
• 升级后重启服务，并复核配置是否被覆盖。

升级是根治手段，配置缓解是争取时间的过渡手段，二者应结合使用。

五、排查与验证：确认自己是否在风险区

5.1 快速自查清单

按顺序核对以下问题：

1. 操作系统是否属于使用该类轻量级 C 库的精简发行版？
2. 服务端是否在编译时未启用可插拔认证模块支持？
3. 配置中密码认证是否为开启状态？
4. 系统中是否存在密码字段为占位符的账户？

若全部为“是”，则处于高风险状态，应立即处置。

5.2 检查账户密码状态

可通过查看密码文件中的密码字段判断：

# 查看密码字段为占位符或空的账户
sudo awk -F: '($2 == "*" || $2 == "") { print $1 }' /etc/shadow

这类账户通常表示“不通过密码登录”，但在本漏洞场景下，恰恰可能成为被绕过的入口。

5.3 验证配置生效

修改配置后，可通过以下方式确认实际生效值：

sudo sshd -T | grep -i passwordauthentication

输出应为 passwordauthentication no。

六、长期加固建议

漏洞处置不应止步于“打补丁”。从架构与运维层面，建议同步推进以下实践：

1. 默认关闭密码认证：将密钥认证或证书认证作为唯一入口，减少凭据类攻击面。
2. 统一认证入口：在条件允许时，通过可插拔认证模块或集中式认证服务统一校验，避免各服务端实现各自为政。
3. 收敛网络暴露面：将管理端口限制在跳板机、专线或零信任网关之后，不直接暴露于公网。
4. 建立配置基线：对服务端配置项做定期审计，确保密码认证、空密码账户等高风险配置处于受控状态。
5. 关注供应链差异：不同发行版在底层库、编译选项上的差异，可能引入意料之外的行为，选型与升级时需把这类差异纳入风险评估。
6. 订阅安全公告：对所用发行版与服务端组件的安全公告建立订阅与响应机制，确保严重级别问题能在小时级而非天级完成处置。

七、小结

本次事件的核心教训在于：安全边界不仅取决于协议与配置，也取决于底层实现之间那些看似不起眼的差异。一个长度区间的边界处理不一致，就足以让“密码认证”这道门形同虚设。

对运维与开发人员而言，行动路径是清晰的：先通过关闭密码认证或停用服务快速止血，再升级到修复版本彻底根治，最后以配置基线与网络收敛构建长期防线。在官方修复全面落地前，任何同时满足四类触发条件的系统，都应被视为已暴露。