平时只用公钥登录的账号，为什么也出现在这次 openssh 漏洞的排查清单里？关键在于，账号没有可用密码，和服务端明确拒绝密码认证，是两回事。alpine 在 11 月 5 日的公告中指出，部分仅使用密钥的账户，在特定服务端环境和配置下仍可能成为认证绕过的目标。alpine 官方公告
密码处理失败，为什么会被当成匹配？
不使用 PAM 时，相关服务端认证路径会调用系统的密码散列函数。Alpine 的分析指出，底层函数在某些情况下返回的错误标记，与部分无密码账号的存储标记相同。旧认证路径未能正确区分两者，导致原本应该失败的检查可能通过。上游把规避措施放进 sshd，因此管理员可以通过更新服务端切断这一条路径。OpenSSH 发布说明
哪些条件叠在一起，才形成风险？
首先，攻击者要能访问 SSH 服务。其次，服务端运行在受影响的 musl 环境中，相关 PAM 路径未启用，且仍接受密码认证。最后，目标账号与同机其他账号必须满足公告描述的存储状态。仅看到 OpenSSH 版本偏旧，或仅看到有账号平时使用密钥，都不足以确认漏洞能触发。
云镜像让风险变成了动态问题
Alpine 特别提到部分旧 tiny-cloud 镜像。初始状态与实际运行状态不同：管理员设置控制台密码或初始化流程创建账户后，机器可能从不满足条件变成满足条件。若被绕过登录的账号还拥有免密提权权限，影响便可能超出该账号本身。这并不等同于每台机器都允许直接以 root 登录。
不同发行版不能按同一个版本线判断
Red Hat 明确其产品不受本 CVE 影响；Alpine 则发布了多个稳定分支的回移补丁。对第三方镜像、自行编译的组件或混合部署，仍需对照实际服务端构建和供应商公告。公开 PoC 的消息说明这个问题值得尽快处置，但不能据此认定任意一台机器已经失陷。Red Hat CVE 页面
