RootGS 安全指南｜2026 年 11 月 6 日（UTC+8）
近期“输入超过256个字符的密码即可登录”的说法，对应的是 OpenSSH 在特定 musl Linux 环境中的密码认证绕过问题。它不是所有 Linux、所有 OpenSSH 账号都能触发的通用漏洞。客户应先核对实际 SSH 服务、C 库、PAM 和账号条件，再依据发行版补丁状态处理。
一、漏洞是什么，哪些条件需要同时满足？
OpenSSH 于2026年11月5日发布10.6p2，修复说明明确涉及 musl libc 且未使用 PAM 的环境。Alpine 公告说明：当密码认证开启、目标账号密码字段为星号 *，并且另一个本地账号使用 $5$ 或 $6$ 哈希时，257～1024字节的密码可能被错误接受。正常密码哈希账号不能直接套用这个结论；root还受 PermitRootLogin 限制。OpenSSH 官方说明；Alpine 官方公告。
关键问题是错误返回值被当成了密码校验结果，而非“密码越长权限越高”。为账号配置过密钥，也不意味着服务器已经关闭密码认证。排查请优先使用下面的只读核查，不要在生产环境反复尝试绕过登录。
二、哪些 Linux 发行版需要关注？
| 环境 | 排查重点 |
|---|---|
| Alpine Linux | 官方明确涉及其未修复的 OpenSSH 软件包；需要检查实际认证条件。 |
| OpenWrt、Buildroot、Yocto及其他定制系统 | 这些环境的组件可以不同。若实际使用 musl 与 OpenSSH，且不经 PAM 验证，则应逐项核查；发行版或构建框架名称本身不是受影响证明。使用 Dropbear 的实例不属于本次 OpenSSH 问题。 |
| Ubuntu、Debian、RHEL/CentOS、Rocky、AlmaLinux 等常见 glibc 环境 | 标准 glibc 构建不符合此问题的 musl 条件。仍应检查自定义二进制、独立容器和设备内置运行环境，不能据宿主机名称替所有实例下结论。 |
| 容器、NAS、软路由、轻量云镜像 | 确认内部是否运行并暴露 OpenSSH 服务；仅使用 Alpine 基础镜像、但没有运行 sshd，不构成这一 SSH 入口。 |
上述非Alpine环境为依据官方触发条件给出的排查范围，不是各发行版已确认受影响清单。为每个对外 SSH 端口记录其实际进程和所属容器，比只查看宿主机的系统名称可靠。
三、怎样核对 OpenSSH 版本和修复包？
上游修复版本是 Portable OpenSSH 10.6p2。此前未带修复补丁的版本需结合触发条件判断；发行版可能回移修复，不能简单把“低于10.6p2”等同于有漏洞。Alpine公布的修复包如下，版本来源为前述官方公告：
| 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 |
这些是公告列出的修复包，并非要求所有客户安装同一分支的包。应使用自己系统分支的软件源和后续修复版本。旧分支获得一次补丁，不代表恢复常规安全支持。
四、客户可以执行的只读排查
在服务器上先核对系统、C库与服务端软件包。以下命令按实际发行版选择，不要把某个命令不存在解释为“安全”：
# 通用：确认操作系统及C库线索
cat /etc/os-release
ldd --version
command -v sshd
# Alpine：查看实际安装的服务端包
apk info -v openssh openssh-server openssh-server-pam
# Debian / Ubuntu：查看服务端包版本
dpkg-query -W openssh-server
# RHEL 系列：查看服务端包版本
rpm -q openssh-serverssh -V展示的是客户端版本，不能单独证明监听端口的服务端版本。存在自编译版本或容器时，还要核对运行进程路径。对可信的系统 sshd 可执行 ldd /usr/sbin/sshd 检查链接库；路径不同则替换为实际位置。宿主机使用glibc，也不能排除某个独立容器使用musl。
以有权限的管理员身份查看有效配置，不要只搜索配置文件中是否出现某一行：
sudo /usr/sbin/sshd -T | grep -E '^(usepam|passwordauthentication|permitrootlogin|authenticationmethods) '重点查看是否启用密码认证、是否使用PAM以及root登录限制。没有PAM支持的构建可能不显示 usepam，不能据此判断PAM已启用。有 Match 条件时，按实际登录用户、来源地址与主机名使用 sshd -T -C 核验对应场景；服务若采用自定义配置文件，也需带上相同的 -f 参数。
如仍满足可疑条件，可由管理员在本地检查账号密码字段类型。下面只输出数量，不输出密码哈希：
sudo awk -F: '
$2 == "*" { star++ }
$2 ~ /^\$[56]\$/ { sha++ }
END {
printf "star_field_accounts=%d\nsha256_or_sha512_accounts=%d\n", star, sha
}' /etc/shadow两项数量均大于零只代表存在相关本地账号条件，不代表所有这些账号都能远程登录；还需考虑shell、访问规则、root限制和认证组合。此检查不覆盖目录服务/NSS账号。不要把 /etc/shadow 全文、私钥或密码发送到客户群；不确定时可向技术支持提供包版本和已脱敏的配置结果。
五、升级或临时缓解时如何避免失联？
建议顺序是：准备控制台或救援入口，保持现有SSH会话，备份配置，验证密钥能够建立第二个独立会话，再安排更新。在维护窗口内使用对应分支官方源提供的修复包。Alpine官方给出的更新方式是：
apk upgrade -U -a
sshd -t && rc-service sshd restart注意：apk upgrade -U -a会更新系统软件包，并非只更新OpenSSH，执行前应评估其他软件的兼容性；rc-service适用于对应OpenRC部署。容器及其他服务管理器应按自身流程替换运行实例。本文仅提供操作指导，不会自动替客户执行这些命令。
安装包更新之后，还要让运行中的sshd使用新程序，并测试新的登录连接。暂不能升级时，可在确认密钥可用后将实际生效的 PasswordAuthentication 设为 no，通过 sshd -t 检查，再按部署方式重启并复核。需考虑Include与Match规则，不要直接追加一行后就认定已生效。
六、如何排查已有异常登录？
关注本应仅允许密钥的账号是否出现 Accepted password for 成功记录，并结合系统审计检查异常提权、新增账号、授权密钥和持久化变更。Alpine可从 /var/log/messages 开始；其他系统也可能使用 /var/log/auth.log、/var/log/secure 或 journal，取决于日志配置。
大量失败记录不能单独证明已被此漏洞利用；没有失败记录也不能排除成功绕过。发现未授权成功登录时，先保存证据、限制访问并联系技术支持，评估重建与凭据轮换，不要仅删除可疑文件后继续使用。我们建议将修复包版本、运行进程切换时间和新登录测试结果一并留档。
七、官方来源与支持
本文面向本次特定认证绕过问题，不能代替完整安全审计。需要协助确认系统、软件包或有效配置的客户，请联系RootGS技术支持。自管服务器需逐台核验，不能把某一台服务器的排查结论套用到所有业务。
