Alpine 和 OpenWrt 用户今晚该做的一件事：关掉密码登录
Alpine 和 OpenWrt 用户今晚该做的一件事：关掉密码登录
最简阅读：
如果不是OpenWrt或者Alpine用户，可以直接关闭这篇文章。如果是，那就升级sshd，不想升级那就关闭密码登录直接用key。
详细版本：
编号 CVE-2026-123158 的漏洞，能让「没设密码」的账户变成「谁都能登进去」——好在堵法极简单：把 SSH 密码登录关掉，再重启服务。用 Debian、Ubuntu 这类常规系统的人，可以直接划走。
这件事跟你有关系吗（对号入座）
| 读者类型 | 影响 | 你要做什么 |
|---|---|---|
| 只刷网页、用手机上网的人 | 基本没影响 | 不用管，唯一要记住的是别乱开路由器的远程 SSH |
| 家里有 OpenWrt / 软路由的人 | 装了 OpenSSH（非默认 dropbear）且开密码登录才中招 | 关密码登录或升级 |
| 有云主机 / 自建服务的人 | 跑 Alpine 的云镜像、轻量 VM、内部跑 sshd 的容器是重灾区 | 照四步做：判断、升级、关密码登录、查日志 |
| 运维与开发者 | 公司里没人管的测试机最可能被扫 | 完整自查，拿发行版公告比对包版本 |
值得花这十分钟
打个比方：没设密码的账户，像一扇锁眼里没有钥匙孔的门。这个漏洞做的事，是让一个「恰好长成那样」的值填进锁眼——你以为锁了门，其实门把手本身就是钥匙。
它值得今晚处理：专挑「没设密码」的账户下手，而很多云镜像、测试机恰恰是「反正没密码」的状态；触发条件在轻量设备上几乎默认凑齐；堵法又极便宜——关一个开关、重启一下，比事后满机器查失陷便宜太多。更普适的习惯是：与其琢磨「设多复杂的密码」，不如「只留密钥登录」，把这扇门直接焊死。
出了什么事
SSH 登录的流程很简单：你报出密码，服务端算一遍，跟账户里存的对上，就放行。没设密码的账户，存的位置不是密码，而是一个星号（*），意思是「这里没密码，谁也不许用密码进来」。
为了不让外人靠「试账户名」判断哪个账户存在，SSH 服务会去「借」别的账户的盐再算一遍——这一步是 2016 年修 CVE-2016-6210（用户名枚举）时加进来的。这个设计本身没问题，问题出在 Alpine 用的更轻的 C 库（musl）：喂给它的密码太长（超过 256 字节）时，它报错的方式不是正常报错，而是返回字符串 *。于是，一段特别长的密码（257 到 1024 字节，1024 是 SSH 服务设的密码上限）算出的「结果」恰好也是 *，SSH 服务一看「对上了」就放行。三件事凑在一起才出事，所以这个组合从 2016 年起一直没被注意到，直到这次才被翻出来。
凑成这个巧合，得同时满足：机器是 musl（Alpine、OpenWrt 装的 OpenSSH、Buildroot / Yocto）+ 没启用 PAM + 开着密码登录 + 有没密码的账户 + 至少还有一个设了密码的账户（$5$/$6$ 哈希供借盐）。Alpine 官方原话：一个设了密码的用户，就足以让所有没密码的账户都可被登录。
漏洞别名 *sshole / SSHole，报告者 Özgün Kültekin（Wakefield）。OpenSSH 认为根因不在自己，但在 10.6p2 加了规避。评分上有个容易看混的地方：CVE 记录给的是 CVSS 3.1 的 8.1（High），而 OpenSSH 发布说明里用了「critical」这个词——前者是评分，后者是官方对严重程度的措辞，不是两个互相打架的分数。
一个具体坑：官方 tiny-cloud 镜像 3.18.11 到 3.24.3 自带 alpine 用户（* 密码字段）+ 免密 doas，刚启动安全；但一旦出现任何 $6$ 哈希（如管理员设了控制台密码），这个用户就能被登进去、再提权到 root。
有没有人已被攻击？要分开说：OpenSSH 和 Alpine 官方截至 11 月 6 日都没报告在野利用；有安全厂商（Cyber Defense Magazine / Horizon3）报道披露后约 9 小时在蜜罐捕获利用尝试并取得 root，未获官方统一确认。确定的是：PoC 已公开，扫描随时会来，按「随时会被扫」处理。
具体怎么做
① 先判断自己是不是「musl 且没开 PAM」
先问一句：这台机器是不是 Alpine、OpenWrt（装的是 OpenSSH）、或 Buildroot / Yocto 出的系统？用 Debian、Ubuntu、Fedora、CentOS 这类常规发行版的，直接跳到「谁不用慌」——它们用的是 glibc，不在这条链上。在 Alpine 上，看自己装的是哪个包：
apk list -I 'openssh*'输出带 -pam 且配置是 UsePAM yes 的，也基本没事。
② 升级，并且一定要重启 sshd
先升级：
apk upgrade -U -a升级完最容易被漏掉的一步：升级不会替换正在跑的 SSH 服务进程，必须手动重启，补丁才生效：
rc-service sshd restart注意：Alpine 的修复是「回移补丁」，版本号可能没变，别用 sshd -V 判断，比对下面的包版本表。
③ 升不动，就先关掉密码登录
暂时升不了级，最直接的缓解是把密码登录整个关掉。动手前先确认你能靠密钥登录、保留当前这个已连上的会话，别把自己锁在门外。Alpine 官方给的整套写法，直接抄：
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication最后一条应输出 passwordauthentication no，看到就算关上了。/etc/ssh/sshd_config.d/ 从 Alpine 3.19 起才被默认读取，老版本靠 sed 那条。Match 块里的设置要用 sshd -T -C user=…,host=…,addr=… 验证（sshd -T 默认忽略 Match 块）。
④ 查日志，看有没有人已经进来过
在 /var/log/messages 里找 Accepted password for，看目标是不是没密码的账户（alpine、root、key-only 用户）。有的话就按「已经失陷」处理：查 doas 记录、新建用户、文件变更、authorized_keys 是否被改。
对比：修复版本表
Alpine 官方公告给出的修复包版本如下：
| 分支 | 修复 openssh 包版本 |
|---|---|
| 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.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Alpine 3.21.10 / 3.22.8 / 3.23.8 / 3.24.4 及之后自带修复包。3.21 已于 2026-11-01 结束支持，但官方仍为 3.16 起的每个分支发布了修复包。
最容易踩的坑：Alpine 的修复是回移补丁，保留旧版本号，所以 sshd -V 显示旧版本号不能说明没修，必须拿 apk list -I 'openssh*' 跟这张表比对。研究者的检测脚本只比版本号，会误报「已修复的 Alpine 主机」——别被误报吓到，也别因版本号没变就以为没修上。
谁不用慌
下面这些情况不受影响：
- glibc 系统：Debian / Ubuntu / Fedora / RHEL / Rocky / AlmaLinux 等常规桌面与服务器发行版。
- 装的是
openssh-server-pam，且配置是UsePAM yes。 - 已设
PasswordAuthentication no的机器。 - 账户用
!锁定（不是*）。 - 机器上没有任何
$5$/$6$哈希。 - 容器里没跑 sshd 的——绝大多数 Docker 容器。
- 经 cloud-init 配置的云镜像（默认
PasswordAuthentication no，除非 user-data 设ssh_pwauth: true）。 - Dropbear、OpenBSD 不在影响范围。
数据 / 来源
- Alpine 官方公告：https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
- OpenSSH 10.6p2 发布说明：https://www.openssh.com/releasenotes.html
- Cloudflare Radar Zero Wire：https://radar.cloudflare.com/security/zero-wire/sshole
- CVE 记录：https://www.cve.org/CVERecord?id=CVE-2026-123158
常见问题
Q1：我用的是 Ubuntu / Debian，要管吗？
答：不用。这条漏洞链的关键一环是 musl，而 Ubuntu、Debian、Fedora、RHEL 等常规发行版用 glibc，不在这条链上。顺手养成「只留密钥登录」的习惯。
Q2：在野利用到底有没有？
答：OpenSSH 和 Alpine 官方截至 11 月 6 日都没报告在野利用；有安全厂商报道披露后约 9 小时在蜜罐捕获利用尝试并取得 root，未获官方统一确认。确定的只有一点：PoC 已公开，扫描随时会来，按「随时会被扫」处理。
Q3：我 sshd -V 还是旧版本号，是不是没修上？
答：不一定。Alpine 的修复是回移补丁、保留旧版本号，sshd -V 不作准，要看 apk list -I 'openssh*' 的包版本跟公告比对。反过来，只比版本号的检测脚本也可能误报「已修好的 Alpine 主机」。
Q4：是不是设个复杂密码就安全了？
答：不是。这个漏洞打的就是「没设密码」的账户——复杂密码防不了「标记撞上标记」。真正省心的是「只留密钥登录」：关掉密码登录，等于把这道门整个焊死。
