有客户早上问我：“我 docker 跑的都是 Alpine，是不是得赶紧换镜像？” 对，你可能真得检查一下。就在这几天，一个叫 SSHole（或者说 *sshole）的漏洞把不少用轻量 Linux 的站长吓出一身冷汗。它让攻击者随便敲一个超长密码就能登录你的 SSH，不需要任何凭据，而且漏洞公开后几小时内就有黑客在蜜罐上成功拿到 root 权限。
为什么输个长密码就绕过了认证？
这个漏洞不是 OpenSSH 自己的锅，而是 OpenSSH 碰上了一个特定组合：musl libc + PAM 禁用。musl 是 Alpine Linux 这类轻量发行版默认的 C 库，很多容器镜像、边缘设备都在用它。当 OpenSSH 在这种环境下编译，并且没有启用 Pluggable Authentication Modules（PAM），就会在处理密码认证时掉进一个内存越界的坑——提交的密码超过 256 字符，就能直接把认证函数绕过去。其结果就是那句粗鲁的代号：只要你知道这个“超长密码”的梗，就能像进自己家一样登进去。
你的服务器在受影响范围吗？
说一个最简单的判断方法：如果你的服务器用的是 Alpine Linux，或者是从 alpine 基础镜像拉起来的 Docker 容器，又在跑 sshd，那大概率中招。其他发行版如果用 musl 编译 OpenSSH 并且没开 PAM，也一样危险。不过，像常见的 CentOS、Ubuntu、Debian 等用的是 glibc，本身不受影响——除非你自己莫名其妙换成了 musl。你可以跑一句：ldd /usr/sbin/sshd | grep musl，如果输出里有 libc.musl，就得赶紧动手了。
黑客已经在利用了吗？
据公开报道，安全公司 Previdian 在漏洞披露（CVE-2026-123158）后不到 10 小时，就在蜜罐里捕获到利用行为。攻击者扫描公网上的 SSH 端口，尝试用超长密码登录，一旦成功就直接上传脚本提权、植入后门，有的蜜罐 root 权限当场失守。要命的是，这次漏洞完全不需要任何技术门槛——就是一个长字符串，连漏洞利用代码都算不上，量产式攻击会来得比以往都快。
补丁怎么打？先看你的环境
Alpine 官方已经在 2026-11-05 当天发布了紧急更新，修复了 musl 库对密码长度的处理。不需要重新编译 OpenSSH，直接 apk update && apk upgrade 把系统包整体拉到最新即可，因为关键修正在 musl 和 OpenSSH 的包里都进去了。如果你不是 Alpine，但确定用了 musl，就需要去你发行版的仓库找对应更新，或者用 Alpine 的动作做参考：确认 musl 版本不低于 1.2.5-r2，OpenSSH 不低于 9.9_p2-r0。
如果你是在微码盒下载的 WordPress 主题或 DedeCMS 模板，站点刚好跑在受影响的容器上，先别管模板的事，服务器安全优先级更高——把系统更新了再说。
来不及打补丁，马上做这三步
有些生产环境不方便立刻重启动服务，或者补丁还在测试，那么临时加固能挡住大部分盲扫：
- 禁用密码登录，只留密钥认证。在 /etc/ssh/sshd_config 里设 PasswordAuthentication no 并重启 sshd。这是最利落的一刀，因为漏洞只走密码认证链路，关了它就绕不过。
- 限制登录来源 IP。用 iptables 或云防火墙把 SSH 端口开放范围缩到只有你自己的办公 IP，外面的扫描直接忽略。
- 临时启用 PAM（如果可行）。部分编译默认禁用了 PAM，可以重新编译或换个官方包。对 Alpine 用户，直接 apk add linux-pam 然后改 UsePAM yes，但需要确认你的 sshd 是不是在编译时支持了 PAM，否则反而可能把服务搞瘫。没把握的话，还是回到前两步。
内地的服务器部署，尤其是用了轻量规划的 WP 站点、测试环境、边缘节点，现在值得花十分钟自查一遍。别等看到陌生登录日志才行动。
