Ing. Calogero Bono
2026年11月5日，OpenSSH 10.6p2发布，修复了一个被称为«*sshole»的漏洞。它影响使用musl库的Linux SSH服务器，例如Alpine Linux，且PAM已被禁用。任何能连到SSH端口的人都可以发送一个超长密码，从而无需密码登录某个账户。这一点很重要，因为只需一次连接即可，而且Alpine官方的云镜像可能直接以root身份开放访问。
在进入具体事实之前，先了解几个术语。 musl是一个替代glibc的C库，被Alpine、OpenWrt、Buildroot和Yocto使用。crypt()是把密码转换为哈希值的函数。PAM是Linux的模块化认证系统。/etc/shadow是保存密码哈希的文件。doas是类似sudo的工具，用于获取root权限。
*sshole漏洞是如何运作的？
Linux中没有密码的账户，在/etc/shadow里的哈希位置是一个星号。按理说，任何密码都不应能打开它。根据BleepingComputer的报道，OpenSSH在2016年的一次修改，原本用于修复CVE-2016-6210这个用户枚举问题，却让它对这些账户也会计算哈希。
问题就出在musl上。正如Alpine的公告所解释，musl的crypt()在密钥超过256字节时，会返回*作为错误信号。这个星号与账户中保存的星号恰好相同，于是比对成功。研究人员Özgün Kültekin表示，该缺陷自2016年起就已存在。
谁真正有风险？
需要多个条件同时满足。据Alpine称，openssh-server软件包编译时未启用PAM，或者使用了UsePAM设为no的openssh-server-pam。PasswordAuthentication必须处于启用状态，这也是默认设置。还需要至少一个哈希为*的账户，以及另一个哈希为$5$或$6$的账户。只要有一个用户设置了密码，就能让其他所有账户变得可以访问。
Alpine验证了3.21至3.24版本和edge版本，以及较早的3.16至3.20版本。不运行sshd的容器、设置了PasswordAuthentication no的系统，以及启用了PAM的系统均不受影响。BleepingComputer报道，使用glibc的Debian、Ubuntu和Fedora不存在漏洞。
为什么Alpine的云镜像令人担忧？
官方tiny-cloud镜像，从3.18.11到3.24.3，都带有一个密码为*的alpine用户，并且doas无需密码。Alpine强调，这些镜像在首次启动时是安全的。一旦出现$6$哈希，问题就会变得可以利用，例如管理员设置了控制台密码，或者user-data通过hashed_passwd添加了用户。
此时攻击者能以alpine身份获得shell，再通过doas提升为root。使用cloud-init配置并设置了PasswordAuthentication no的镜像不受影响。对于root账户，默认的PermitRootLogin prohibit-password只在直接登录的情况下起保护作用。
如何修复，以及如何检查是否遭受攻击？
修复方法是升级到OpenSSH 10.6p2。在Alpine上执行apk upgrade -U -a，然后重启sshd，因为仅升级并不会替换正在运行的进程。Alpine还为已停止支持的版本发布了修复包，最早可回溯到3.16。
如果暂时无法升级，请设置PasswordAuthentication no并重启sshd，同时先确认密钥登录可以正常使用。要排查攻击痕迹，可以在/var/log/messages中查找针对无密码账户的«Accepted password»记录。Alpine还补充说，如果无法排除有人已经登录，就应将该机器视为已被入侵。账户权限方面，可以参考Linux权限指南。
需要了解的局限
Alpine在发布时表示尚未分配任何CVE编号。OpenSSH写道，问题的根源位于sshd之外，但可以通过sshd触发，并在那里被阻断。目前没有真实攻击的相关数据。关于17600次AI代理测试的说法来自研究人员，由BleepingComputer转述，未经独立核实。
这对数字领域从业者意味着什么
如果你管理Alpine服务器、OpenWrt路由器，或使用Yocto和Buildroot的嵌入式系统，请检查sshd是否允许密码登录，以及是否存在哈希为*的账户。许多人在不运行sshd的容器中使用Alpine，这些不受影响。使用tiny-cloud镜像的云主机，则需要逐一检查已在运行的实例。定期更新的托管服务器能降低此类风险，相关内容见托管与服务器管理页面。另外，也可以关注与之相关的AI生成漏洞利用案例，我们在这篇文章中报道过。
我们的看法
这一事件说明，相互信任的组件之间的边界有多脆弱。OpenSSH在2016年加入了一项合理的防护，musl选择了一个常见的错误返回值，二者结合却在十年间留下了一扇门。发现该漏洞的过程借助了AI代理，这也值得注意。OpenSSH本身提醒，借助AI发现的漏洞常常会被其他人重新发现，因此等待本身就是一种风险。最稳妥的做法依然如故，用密钥代替密码。
常见问题
Debian和Ubuntu会受*sshole影响吗？
不会。它们使用glibc而不是musl库。BleepingComputer确认，采用PAM认证的系统不受影响，但Alpine指出，openssh-server-pam在UsePAM设为no时不受影响，设为yes时则不然。
只更新openssh软件包就够了吗？
不够，还需要重启sshd。Alpine提醒，更新软件包并不会替换正在运行的守护进程，因此有漏洞的版本仍会继续运行。
不更新能否临时防护？
可以。在sshd配置中设置PasswordAuthentication no并重启服务即可。操作前先确认密钥登录正常。
root账户也会暴露吗？
只在特定情况下。默认的PermitRootLogin prohibit-password设置下，root无法被直接访问。如果启用了PermitRootLogin yes，或者其他用户能通过doas提升为root，风险就会出现。
这个漏洞有CVE编号吗？
据Alpine称，目前还没有。其公告写明，撰写时尚未分配任何标识符。可参考的依据是OpenSSH 10.6p2的更新说明。
OpenSSH 10.6p2之后该关注什么
OpenSSH表示将更频繁地发布版本，以便更快地把修复交付给用户。这个漏洞仍留下一些需要跟进的问题。
- 留意是否会分配CVE编号，以及你的扫描工具能否识别它。
- 关注基于OpenWrt、Buildroot和Yocto的固件厂商何时发布更新。
- 建立一套流程，在不等待计划版本的情况下安装OpenSSH的小版本更新。
