/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
2026 年 11 月 5 日，OpenSSH 紧急发布了 Portable 10.6p2 版本，修复一个足以让安全圈倒吸一口凉气的漏洞：远程攻击者只需输入一个异常长的密码，就能绕过 Alpine Linux 服务器上的密码验证，就连那些只允许密钥登录、理论上"绝对安全"的账户，也可能在毫不知情的情况下被陌生人接管。更令人不安的是，漏洞披露时甚至连 CVE 编号都还没来得及分配。
这个被研究人员戏称为"SSHHole"的漏洞，由安全研究者 Özgün Kültekin 在 sshhole.com 上首次公开。他的实验表明，在满足特定条件时，发起攻击所需要的全部条件只有一个开放的网络连接、一个可达的 SSH 端口，以及一个已知的账户名。Alpine 官方随后证实了这一判断。
漏洞的诡异之处，在于它把几个看似无害的设计细节串成了一条完整的攻击链。目标账户的密码字段必须是一个特定的占位标记，而系统中另一个本地账户必须存有以 5 或 6 开头的密码哈希，同时密码验证处于启用状态。换句话说，管理员随手给一个账户设置了密码，反而可能把其他从未设过密码的账户暴露在枪口之下。
要理解这台"多米诺骨牌"是如何倒下的，需要把目光投向 OpenSSH 与 musl libc 之间一次微妙的交互。在不启用 PAM 的系统中，sshd 会对用户提交的密码调用 crypt() 函数进行哈希，再与存储的密码字段比对。当目标账户的密码字段恰好是那个特殊的占位标记时，sshd 会"借用"另一个账户的盐值来完成计算——这是 OpenSSH 早在 2016 年为减少用户名泄露而引入的机制，初衷本无问题。
真正的裂缝出现在 musl 这一侧。当提交的密码长度超过 256 字节时，musl 的密码哈希代码会直接拒绝处理并返回一个错误标记。戏剧性的一幕发生了：这个错误标记与目标账户中存储的占位字段完全一致，比对"通过"了，登录就这样莫名其妙地成功了。Alpine 将 257 到 1024 字节之间的密码长度圈定为触发区间，而在实际环境中，一个由 300 个重复字母 A 组成的"密码"，就足以骗过本应铁面无私的验证环节。
Alpine 的标准 openssh-server 软件包恰好默认不走 PAM，这让大量生产环境恰好踩中了触发条件。值得宽慰的是，安装 openssh-server-pam 并启用 UsePAM yes 的系统不受波及，纯粹作为容器镜像运行、没有开启 SSH 服务的 Alpine 同样安然无恙。
风险的真实分量，藏在 Alpine 官方 tiny-cloud 镜像的默认配置里。3.18.11 至 3.24.3 这些版本的镜像自带一个无需密码即可使用 doas 的 alpine 账户，一旦该账户被补上符合条件的密码哈希，攻击者就能以这个账户为跳板登录系统，再借助 doas 直接拿到 root 权限。好在除非管理员主动改动默认限制，root 账户本身仍不允许密码直接登录，这算是混乱中仅存的一道闸门。
修复动作必须干净利落，拖延不得。管理员应尽快执行 apk upgrade -U -a 完成 Alpine 的修复更新，随后运行 rc-service sshd restart 重启 SSH 服务——只更新软件包而不重启守护进程，旧进程会继续在内存中运行，漏洞依旧敞开。已经放出的修复版本覆盖 3.21.10、3.22.8、3.23.8 和 3.24.4，旧分支同样获得了回移补丁，所以版本号偏低并不等于系统仍然处在危险之中。
如果补丁暂时无法落地，临时加固措施也能争取时间。先把 PasswordAuthentication 设为 no 并切换到密钥登录，确认新机制生效后再重启 sshd，整个过程中务必保持现有会话不断开，避免把自己锁在门外。事后应当翻查 /var/log/messages，留意是否出现过 Accepted password 与无密码账户相关联的可疑记录，同时检查有没有异常的 doas 调用和新冒出来的授权密钥。
OpenSSH 的发行说明印证了上游提供的这一变通方案，但 Alpine 的态度十分明确：如果无法排除未经授权的访问，就应当把这台机器视为已经失陷，按入侵事件流程处置，而不是心存侥幸地打个补丁了事。
这一次的事件与此前 OpenSSH 客户端和服务端那些涉及拦截、服务中断的漏洞都不太一样，它攻击的不是加密算法，而是密码检查这条看似最不起眼的路径。研究人员用一幅漫画还原了事情的全貌：对无密码占位账户的处理方式、musl 的错误标记、OpenSSH 的借盐机制，三个各自独立演进了多年的设计，在某个无人留意的角落悄然咬合，最终让一个超长的密码穿透了本应拒绝它的每一道检查。
对于运维团队来说，这起事件留下的启示远不止"记得打补丁"那么简单。任何把密码验证与底层 libc 行为捆绑在一起的系统，都值得重新审视一遍认证链路的每一个环节——因为下一个洞，可能就藏在那个所有人都默认"不会出错"的函数返回值里。
