1980年，Unix开发者Bill Joy在不应有人登录的daemon账户的密码字段中插入了星号（*）。当时，密码哈希值也存储在任何人可读的/etc/passwd中。由于*并非哈希密码，因此无法与任何密码匹配，从而起到了从根本上阻止登录的作用。在同一字段条目的姓名（real name）字段中，写有“the devil himself”1。

然而，在2026年，这个*却变成了允许输入“257至1024个字符之间的任意字符”即可通过的钥匙。发现这一问题的研究人员公开了“sshhole”漏洞，该漏洞产生的原因是：服务器为了防止计时攻击而试图通过响应时间差异隐藏账户信息的防御逻辑，与Linux库musl的密码长度限制偶然重叠所致2。该漏洞尤其在Alpine Linux或OpenWrt等未使用PAM（可插拔认证模块）的轻量级环境中出现。此问题已在OpenSSH 10.6p2版本（2026年11月5日发布）中修复3。

1980年用于阻止“任何人登录”的*在46年后变成钥匙的故事

*成为钥匙的过程：三条规则冲突

sshhole漏洞的发生，是因为在不同时期、出于不同目的建立的三个安全机制在一行比较运算中相遇。每个机制单独看都是合理的，但组合在一起时却导致了认证绕过。

  1. musl库中失败返回值的变更（2012年）： 作为C标准库之一的musl，修改了crypt()函数（计算密码哈希值的函数），使其在失败时返回*而非NULL。此举是为了防止因开发者未处理NULL值而导致程序崩溃。由于正常的密码哈希值形式如$6$salt$hash，开发者认为*不会与实际密码匹配2。

  2. 256字符长度限制的引入（2012年）： 同一时期，musl对SHA-512哈希计算施加了256字节的长度限制。由于密码越长计算时间越久，因此旨在防止过长的输入长期占用服务器从而影响其他连接。当输入超过256个字符时，系统不进行计算，直接返回失败值*2。

  3. OpenSSH的计时攻击防御（2016年）： OpenSSH为了阻止黑客通过响应时间变短来推断账户信息的计时攻击，在访问“不存在的账户”时修改了逻辑（CVE-2016-6210）。原先，当尝试登录没有哈希值的账户（如*等）时，会立即拒绝；但修改后，为了模拟实际哈希计算，它会借用“其他账户的盐值（安全随机数）”，虚拟地计算哈希值后再返回失败2。

冲突点： 对于标记为*的账户，如果使用257个字符以上（1024个字符以下）的密码进行访问，认证将按以下流程通过。注意，要使此绕过生效，前提是该账户此前曾因输入常见长度的错误密码而登录失败过一次2。

  1. OpenSSH判断存储值为*，因此无法进行实际哈希计算。
  2. 为了保持计时一致性，它借用其他账户的盐值，尝试使用用户输入的257个字符密码计算哈希值。
  3. 由于服务器正在使用musl库，对于超过256个字符的输入，计算结果返回*。
  4. 服务器判断“计算结果（*）”与“存储的密码字段（*）”作为字符串完全一致，从而处理为认证成功2。

通过17,600次测试验证的条件

此漏洞并非在所有服务器上都会出现。运营sshhole.com并公开此问题的研究人员，组合了glibc与musl库、是否使用PAM以及shadow文件设置，制作了多个OpenSSH构建版本。通过进行约17,600次异常登录尝试，结果确认仅在“使用musl库且禁用PAM的构建版本”中，此认证绕过才会成功2。

大多数普通Linux发行版（如Debian、Ubuntu、Fedora等）均使用PAM认证模块。PAM在密码字段为*时，甚至不调用哈希计算函数（crypt()）就直接拒绝认证，因此在一般环境中不会受到此漏洞的影响。OpenSSH项目自身的测试环境主要集中在OpenBSD和glibc上，导致这种特殊的“musl + PAM禁用”组合长期以来未得到验证2。

Alpine云镜像的现实威胁

sshhole之所以尤其令人担忧，是因为Alpine Linux的官方云镜像（如AWS、Azure等）默认具备触发此漏洞的条件。

Alpine在2019年之前的版本中，由于root账户密码为空，导致存在可通过空密码登录的问题（CVE-2019-5021）。为了解决此问题，密码字段被更改为!，但在不使用PAM的环境中，如果将其设置为!，则会产生连SSH密钥认证也被一并阻断的副作用。因此，从Alpine 3.16版本（2022年）开始，为了保留密钥登录功能，密码字段又被改回为*2, 4。

默认状态下的Alpine官方云镜像设置了PasswordAuthentication yes和UsePAM no。此外，默认生成的alpine账户被配置为可以在无密码的情况下使用doas（命令权限提升工具）。因此，攻击者可以使用257至1024个字符的任意字符串登录到alpine账户，然后通过doas命令在无需额外认证的情况下立即获取root权限2。

即时应对及检查方法

即时应对及检查方法

sshhole漏洞已在OpenSSH 10.6p2版本（2026年11月5日发布）中得到官方修复3。

1. 更新 最安全的措施是将OpenSSH更新至10.6p2或更高版本。在Alpine Linux中，可以通过以下命令进行更新。

bash
apk upgrade openssh

2. 更改设置 如果无法进行更新，则应禁用密码认证本身。在/etc/ssh/sshd_config.d/00-no-passwords.conf等设置文件中添加以下内容。

text
PasswordAuthentication no

更改设置后，在Alpine Linux中必须使用rc-service sshd restart命令重启SSH服务方可生效2。

3. 检查是否入侵 若要检查服务器是否已被入侵，需查看服务器日志。如果存在密码字段确切为*的账户通过“密码认证方式”成功登录的记录，则需探讨是否可能利用了此漏洞2。

参考资料

  1. *sshole · sshhole.com · sshhole.com
    ↩
  2. ↩
  3. OpenSSH · openssh.org
    ↩
  4. ↩