很多搞网路资安的朋友头发可能又要掉好几根了，近日爆出当你在Alpine Linux 上用SSH 连线，只要密码输入超过256 个字元，就能以root 权限成功登入系统。攻击者不需要知道任何密码，一次连线就能进入，不必重试，也不会被锁。这个名为*sshole的漏洞（真幽默）由安全研究者Özgün Kültekin 在2026 年11 月5 日公开，他自行架设的说明网站sshhole.com直接用一句话概括：「是的，任何密码。是的。是的，我知道。是的。」
OpenSSH 团队在同日释出10.6p2 版本修补这项缺陷，Alpine Linux 也为旗下所有发行版推出更新套件。 OpenSSH 专案成员Damien Miller 对媒体表示，目前尚未接获任何利用此漏洞的攻击通报。漏洞的触发条件相当严苛，根因落在C 语言函式库与SSH 伺服器的交界处，牵涉一场延续将近十年的修补副作用。
漏洞触及的是哪些系统
Alpine官方安全公告列出的受影响条件，必须同时成立才会中标：
- musl libc 系统：Alpine Linux、OpenWrt、Buildroot、Yocto。这是OpenSSH 编译时未启用PAM 的典型环境
- PAM 关闭：Alpine 的
openssh-server套件预设不编译PAM。若改用openssh-server-pam并设置UsePAM yes，则不受影响 PasswordAuthentication yes：OpenSSH 的预设值，管理者通常不会去改- 至少一个帐号的密码栏位是
*：代表该帐号没有设置密码。这在Alpine 很常见，root从3.16 版起在基础映像中就是root:*；用adduser建立但没给密码的使用者、通过musl-nscd 连入的目录服务帐号同样符合 - 至少一个本机帐号有
$5$或$6$的密码杂凑：也就是真的有设置密码的帐号
最后一项条件最关键。只要机器上有一个设了密码的帐号，所有没有密码的帐号就会一并暴露，攻击者只要知道其中一个帐号名称就能登入。 Alpine 官方测试的结果是，受影响版本涵盖3.16 到3.24 以及edge 开发分支所有版本。 （此漏洞只发生在Alpine Linux）
至于root 帐号，OpenSSH 预设的PermitRootLogin prohibit-password挡住了直接登入，只有设置成PermitRootLogin yes才会直接暴露。但这道防护挡不住提权路径。 Alpine 官方tiny-cloud 映像（qcow2、VHD、AMI 格式）从3.18.11 到3.24.3 都内置一个密码栏位为*的alpine帐号，且拥有免密码的doas权限。这些映像首次开机时是安全的，一旦管理员设置了主控台密码、或user-data加入带hashed_passwd的使用者，机器就会被打通，攻击者登入alpine后再通过doas升级为root。
为什么十年都没人发现
Kültekin 在自己的说明页面列出几个原因：全新安装、没有设置任何密码的机器不会受影响；shadow 文件里是 的*帐号需要先错一次才会触发；OpenSSH 在OpenBSD 与glibc 系统上测试，musl 这条路径不在测试范围；多数发行版走PAM，而PAM 对*栏位根本不会呼叫crypt。
他也在页面上整理了几次擦身而过的纪录。 2013 年7 月，一位Debian 开发者曾要求glibc 复制musl 的星号行为；六年后Debian 转用libxcrypt，该函式库回传*0，距离关闭这个bug 只差一个字元。 2024 年12 月底musl 邮件讨论列表讨论busybox 的passwd在257 字元密码上出错，同样的限制、同样的星号，但没有人把它和sshd 连在一起。
最接近的一次发生在2026 年10 月30 日，OpenSSH 一次安全审查刚好修正了pick_salt()的问题。 Kültekin 写道，那个bug 就在该函式下方四行，四天后他才找到。
修补方式与版本选择
OpenSSH 10.6p2 的修法是让sshd 在密码栏位长度少于四个字元时拒绝比对。官方把这项改动称为workaround，并明确说明根因位于sshd 之外。漏洞由Wakefield 的Özgün Kültekin 通报。
Alpine 为每个分支都制作了带相同修补的套件：edge 分支10.6_p2-r0、3.24 分支10.3_p1-r2、3.23 分支10.2_p1-r1、3.22 分支10.0_p1-r11、3.21 分支9.9_p2-r1，往下到3.16 分支的9.0_p1-r6。其中3.21 已在2026 年11 月1 日终止支援。
官方提醒了一个容易踩到的陷阱：只更新套件不会重新启动执行中的sshd，必须另外执行rc-service sshd restart。无法立即更新的管理者，则可设置PasswordAuthentication no关闭密码登入，Alpine 公告提供了建立drop-in 设置档与检查sshd -T输出的完整指令。
要确认是否遭到利用，公告建议检查/var/log/messages中出现Accepted password for却对应到无密码帐号的纪录，例如alpine、root或仅用金钥的使用者。公告并直言，若无法排除有登入发生，就当作机器已被入侵处理。
AI 代理参与漏洞挖掘
Kültekin 描述自己的发现过程时提到，他建置了多种组合的sshd，包含glibc、musl、有无PAM、有无shadow 等变体，并丢出约17,600 次刻意设计的登入测试，涵盖异常杂凑值、损坏的帐号与超长密码。他在说明页面还补了一句：「抱歉我说了『我』，跑的是一大群AI agent」。
OpenSSH 团队对这次漏洞的态度同样值得记录。 Miller 在发布说明中提到，近期收到大量由AI 模型或AI 协助完成的安全漏洞通报，团队目前采取较频繁的释出节奏，把修补尽快送到使用者手上，而非累积到下一个预定版本。他的理由是，已经出现AI 工具找出某个bug 之后，另一位研究者独立重现同一问题的情形，不向开源专案回报的攻击者同样有办法找到。他也提到近期看过AI agent 在几小时内重复找出相同漏洞，因此长期的保密期对攻击者反而更有利。
结语
如果您不是Alpine Linux 使用者的话也不用太担心，Linux 核心没有问题，OpenSSH 也不是漏洞来源，触发点是musl 的crypt()在错误处理上的设计选择，与OpenSSH 为修补使用者名称枚举而做的副作用相互交叠。影响范围限于musl 生态圈，Debian、Ubuntu、Fedora 等glibc 系统与所有走PAM 验证的环境都不受影响。
但把它轻描淡写同样不妥。触发条件虽然严苛，却涵盖了Alpine 这个容器与云端映像使用极广的发行版全数版本，而tiny-cloud 映像内置的alpine帐号搭配免密码doas，让攻击者拿到的是root 权限。一次连线即成功、无须重试、也不会触发封锁机制，这些特性让它在渗透测试与自动化扫描中格外好用。
修补工作已经完成，OpenSSH 10.6p2 与Alpine 各分支套件都已就绪，官方并未接到实际攻击通报。对管理者而言，剩下的是一件不需要犹豫的例行工作：更新套件、重新启动sshd、确认sshd -T的输出符合预期。
