OpenSSH 在 11 月 5 日发布 10.6p2，修了一个密码登录绕过漏洞 CVE-2026-123158（发现者叫它 sshole，CVSS 8.1）。11 月 9 日，美国网络安全和基础设施安全局（CISA）以已有在野利用证据为由把它列入已知被利用漏洞目录（KEV）。它只影响使用 musl C 库、且不走 PAM 的 Linux，典型的就是 Alpine。Ubuntu 的安全页面把所有版本的 openssh 都标为「Not affected」，Debian 把它的紧急程度标为 unimportant，所以装着 Ubuntu 或 Debian 的 VPS 本身不用为这个漏洞动手。要查的是 Alpine 系统，以及你在 Alpine 容器里自己装的 sshd。上一次 OpenSSH 的版本变化见我们 10 月的报道。
四个条件同时成立才会中招
- 运行的是 Alpine 的 openssh-server 包（它编译时不带 PAM），或者用了 openssh-server-pam 但配置成
UsePAM no。 PasswordAuthentication是 yes。这是 OpenSSH 的默认值，没改过就是开着的。- 机器上有密码字段是
*的账号，也就是没设密码、只打算用密钥登录的账号。Alpine 从 3.16 前后起基础镜像里的 root 就是root:*；官方 tiny-cloud 云镜像里的 alpine 用户也是，而且它能免密码 doas 到 root。root 自己受默认的PermitRootLogin prohibit-password保护，但只要有别的账号能提权到 root，这层保护就不够。 - 机器上至少还有一个账号存着
$5$或$6$开头的真实密码哈希。四条都满足时，攻击者只要知道账号名，发一个 257 到 1024 字节的超长密码（NVD 的写法是 256 到 1024 个字符）就能登录，一次连接就成功。原因是 musl 的 crypt() 在密码超过 256 字节时返回*表示出错，而这些账号存的恰好也是*，sshd 一比较就当成密码正确。
哪些情况不受影响
- 容器里没有运行 sshd 的，绝大多数 Docker 容器属于这一类。
- 已经设了
PasswordAuthentication no的；用 cloud-init 配置的云镜像会写上这一条。用 openssh-server-pam 并且UsePAM yes的也不受影响。 - 发现者另外点名了 OpenWrt、Buildroot、Yocto 这几类用 musl 的系统，它们只有装了 OpenSSH 的 sshd 才相关，修复看各自的更新。
怎么修
- 升级后重启 sshd：
apk upgrade -U -a，再执行rc-service sshd restart。升级软件包不会替你重启正在运行的 sshd。Alpine 3.21.10、3.22.8、3.23.8、3.24.4 带着修好的包，各分支的包版本是 3.24 的10.3_p1-r2、3.23 的10.2_p1-r1、3.22 的10.0_p1-r11、3.21 的9.9_p2-r1和 edge 的10.6_p2-r0，更老的分支一直回补到 3.16。 - 暂时升级不了，就关掉密码登录：在 sshd 配置里写
PasswordAuthentication no并重启 sshd，再用sshd -T | grep -i passwordauthentication确认输出是 no。动手前先确认密钥能登录，并保留当前会话不要断开。 - 自己写 Dockerfile、在 Alpine 镜像里装了 openssh-server 的，要拉新的基础镜像重新构建并重启容器。只升级宿主机没有用。
怎么判断有没有被登录过
Alpine 的说法是看 /var/log/messages 里 sshd 的 Accepted password for 记录：如果登录成功的是一个根本没设密码的账号（alpine、root 或只用密钥的用户），那就是被利用了；再查 doas 的使用记录、新建的用户和 authorized_keys，排除不了就按已被入侵处理，步骤见入侵排查与安全加固。据 BleepingComputer 11 月 9 日报道，GreyNoise 记录到的第一次成功利用发生在 11 月 7 日 00:46 UTC，离修复发布大约 40 小时；攻击者得手后会侦察系统和容器、查询云平台的元数据接口、尝试读取密码哈希和 root 的 SSH 密钥，并改写 authorized_keys 留后门。容器的基本用法见Docker 入门；不管用哪个发行版，把 SSH 改成只用密钥登录都是最省心的做法，见ufw 防火墙与 SSH 密钥登录。