OpenSSH 紧急修复：Alpine Linux 登录绕过漏洞解析与实操范例

设想一个没有密码的服务器账户。再设想一下，攻击者居然仍然能够登录该账户，原因是在密码校验过程中误将一条错误信息当成了正确答案。这就是本周 OpenSSH 紧急发布版本所解决的核心漏洞。

今天是 2026 年 11 月 6 日，这之所以迫在眉睫，是因为 Portable OpenSSH 10.6p2 就在昨天（11 月 5 日）刚刚发布，并附带了项目方的紧急呼吁。如果您运行了基于 musl 且启用了密码身份验证的 Linux 服务器，开发团队希望您在采取进一步措施之前，立即禁用密码登录或停用 SSH。

许多团队看到这一标题后，要么惊慌失措，要么不屑一顾。这两种反应都是错误的。大多数 Linux 服务器并未受影响，但在受影响的服务器中，可能包含您一直自认为“仅限密钥”的机器。本指南用通俗易懂的语言解析该漏洞，详细展示如何对服务器进行排查，并带您走完从发现问题到验证修复的完整范例流程。

简而言之：究竟发生了什么

SSH 是管理员用于远程登录服务器的工具。OpenSSH 是其中应用最广泛的实现版本。

每个 Linux 程序都依赖于 C 标准库（提供基础通用函数的共享集合）。大多数 Linux 系统使用的是 glibc。而 Alpine Linux 使用的是一个更小巧的库 musl，这也是 Alpine 在容器和轻量云服务器中广受欢迎的主要原因。

该漏洞正存在于这两款软件的交互结合处。OpenSSH 的开发团队认为根本原因并不在 OpenSSH 本身，但他们也认识到 SSH 服务器不仅提供了利用该漏洞的途径，而且是进行有效阻断的切入点。因此，10.6p2 版本添加了针对性的规避方案。该漏洞由 Wakefield 的 Özgün Kültekin 发现。

错误信息是如何演变成成功登录的

以下是逐步梳理的运作逻辑（不包含漏洞利用细节）。

当服务器在不使用 PAM（可插拔认证模块，一种常用的登录处理系统）的情况下校验密码时，其处理逻辑非常简单：先对访问者输入的密码进行哈希运算，然后将计算结果与该账户存储的值进行比对。

哈希运算需要盐值（salt），即混入其中的一小段随机值，以便让相同的密码产生不同的哈希结果。如果某个账户存储的值太短以至于无法提供盐值，OpenSSH 可以借用同一台机器上另一个账户的盐值。这样做有一个合理的出发点：自 2016 年以来，它就试图防止攻击者猜解存在的用户名，这是对 CVE-2016-6210 漏洞的回应。

现在来看冲突所在。当 musl 的 crypt() 函数接收到对于某些哈希类型来说过长的密码时，它会拒绝处理并返回单个字符 * 以表示错误。

但是， * 也恰恰是许多系统在不应该拥有密码的账户密码字段中所存储的值。

因此，服务器比对了这两个值：

• 它计算得出的值： *，实际代表“错误”。
• 它已存储的值： *，实际代表“无可用密码”。

二者匹配成功。登录得以通过。

这就像门卫对着名单核对访客姓名。扫描仪发生故障并打印出“ERROR”。而名单上的某个条目（作为工作人员的备忘说明添加的）也写着“ERROR”。门卫看到两个词一模一样，便招手放行。没有任何人撒谎，各组件也都在按规定执行。危险正源于同一个值被赋予了两种截然不同的含义。

研究人员将该交互追溯到 2012 年 musl 的改动以及 2016 年 OpenSSH 的那次修改。他报告称，在 AI Agent 的协助下，通过跨构建版本和登录组合进行了约 17,600 次测试登录，最终发现了这一漏洞。

您是否受影响？需满足的四个条件

Alpine 安全通告列出了四个条件，且缺一不可：

1. OpenSSH 在未使用 PAM 的情况下校验密码。
2. PasswordAuthentication 已启用。
3. 目标账户的密码字段包含 *.
4. 另一个本地账户的密码哈希以 $5$ 或 $6$.

Alpine 的标准 openssh-server 软件包不使用 PAM。即便安装了 openssh-server-pam 也无法解决问题，因为如果设置了 UsePAM no ，您依然面临风险暴露。

以下情况均不在受影响范围之内：

• 非 Linux 平台。
• 使用 glibc 的 Linux 系统。
• 通过 PAM 校验密码的 Linux 系统。
• 未运行 SSH 服务器的容器。
• 已禁用密码身份验证的系统。
• 使用 ! 而非 *.

这最后一组情况正说明了“我们使用 Alpine”并不等同于“我们存在漏洞”。绝大多数 Alpine 容器根本没有运行 SSH 服务器。同样，“已安装 OpenSSH”本身能提供的信息也极其有限。您需要了解所用的 C 库、软件包、运行配置以及账户数据。

高危场景：官方云镜像

Alpine 特别指出了一个典型场景。其版本从 3.18.11 到 3.24.3 的官方 tiny-cloud 镜像中，包含一个 alpine 账户，该账户具有 * 密码字段，并拥有免密 doas 权限。 doas 是一个小巧的工具，类似于 sudo，允许用户以 root 身份执行命令。

这些镜像初始状态是安全的，因为缺少第四个条件：机器上并不存在符合条件的密码哈希。

随后有人出于控制台访问等需要添加了一个带有常规密码的用户。这一例行的变动就能补齐所有条件。攻击者便能以 alpine 身份登入并提权至 root。

默认的 PermitRootLogin prohibit-password 设置在此处无济于事。它虽然能阻止直接通过密码登录 root，但这种攻击路径是通过间接方式获取 root 权限的。

实操范例：Acme 公司的跳板机

让我们以一家虚构的公司为例。Acme 运行着一台小型 Alpine 服务器 bastion.example.com，员工通过它连接内部系统。大家都认为该服务器仅限密钥登录。新入职的工程师 Rohit 被要求对此进行核实验证。

步骤 1：确认系统平台

Rohit 登录并检查系统：

cat /etc/alpine-release
ldd --version
apk info -e openssh-server openssh-server-pam

第一条命令显示 Alpine 版本。第二条确认了 musl。第三条列出了这两个包中安装了哪一个。在 Acme 的服务器上，仅显示了 openssh-server ，因此不存在 PAM。

如果 ldd --version 显示的名称是 glibc，或者该机器并未运行 SSH 服务器，他们就可以就此停止并转向下一台系统。

步骤 2：读取 sshd 实际强制执行的配置

这是各团队经常忽略的一步。不要只是查看配置文件就做假定。请直接向服务器查询其实际生效的设置：

sshd -T | grep -iE '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods)'

Rohit 看到了以下内容：

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

出人意料的事情发生了：密码登录是开启的。由于员工一直使用密钥，之前无人注意到这一点。未集成 PAM 的构建版本可能根本不会输出 usepam ，这就是为什么该输出中没有这一行的原因。

设置还可能因连接不同而通过 Match 规则发生变化，因此他们测试了针对特定用户和地址的生效配置视图：

sshd -T -C user=deploy,host=bastion.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication'

步骤 3：检查账户数据

以 root 身份运行，这两条命令只输出账户名称，绝不会输出哈希值：

awk -F: '$2 == "*" {print "star: " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "hash: " $1}' /etc/shadow

Rohit 的查询结果：

star: deploy
hash: backup-admin

因此， deploy这个“仅限密钥”的账户拥有 * 字段。而 backup-admin（去年为控制台访问创建）则拥有符合条件的哈希值。全部四个条件均已满足。该服务器处于暴露状态。

步骤 4：先关闭隐患大门，再打补丁

Rohit 保持当前的会话处于打开状态，并从第二个终端确认其密钥依然可用。在这里一旦失误可能会将所有人锁在外面，而保持打开的会话就是救命的安全绳。

他们将该配置添加到 /etc/ssh/sshd_config:

PasswordAuthentication no

一个陷阱是：对于大多数配置项，OpenSSH 会采用其读取到的第一个值。如果文件顶部附近有 Include 行，或者后文有 Match 块，新添加的行可能不会生效。这就是为什么在编辑之后要立即进行检查：

sshd -t
sshd -T | grep -i '^passwordauthentication'

sshd -t 用于测试配置是否存在错误。若测试通过，他们便应用 Alpine 发布的修复补丁。Alpine 已发布 3.21.10、3.22.8、3.23.8 和 3.24.4 版本，在 OpenRC 系统上的修复命令为：

apk upgrade -U -a
rc-service sshd restart

重启服务是必不可少的。安装软件包并不会替换掉已经在内存中运行的 SSH 服务器进程。

步骤 5：从外部进行验证

现在 Rohit 像外部人员一样，从另一台机器对自己这台服务器进行测试：

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

他们希望得到的响应是类似 Permission denied (publickey)的拒绝信息。这表明服务器完全不再提供密码认证选项。随后他们在新的终端中打开一个正常的基于密钥的会话，以确认员工仍可正常登入。

步骤 6：排查过往是否存在异常行为

打补丁关上了大门，但无法证明此前是否有人已经潜入。Alpine 建议在日志中重点审查这条确切记录：

grep 'Accepted password for' /var/log/messages

在员工全部使用密钥的服务器上，一次成功的密码登录就是需要排查追踪的信号。仅针对多次失败进行告警的监控可能会完全漏掉这一点，因为在这里攻击者的尝试表现为登录成功。

Rohit 未发现任何此类记录。如果发现了针对 deploy的记录，工作性质就将从打补丁转变为事件应急响应。Alpine 建议排查是否存在提权行为、新增用户、新增文件以及已修改的 authorized_keys，若无法排除未授权登录，则应将该主机视作已失陷处理。该账户能够触及的任何资产（包括存储的凭据和部署机密）都需要进行审查与更换。

同时还要检查在任何可疑登录发生时该账户的历史状态，因为其当前状态可能反映的是后来的变更。

步骤 7：从源头镜像修复，而非仅修补单机

Acme 是基于已保存的镜像来构建服务器的。如果 Rohit 仅停留在步骤 6，下一次重新构建或自动扩缩容事件就会直接带回原先旧的配置。他们更新了镜像模板，在其中配置了 PasswordAuthentication no ，并追问为什么 backup-admin 一开始会需要密码。

如何解读扫描结果

预计本周的扫描报告会产生大量干扰噪音。请明确区分两个不同层面的概念。

上游版本号字符串与发行版的补丁状态代表不同的事实证据。厂商可能会在不改变主版本号的情况下反向移植修复补丁，因此请以您的发行版软件包指引为准。如果您自行编译 OpenSSH，请参考 10.6p2 的发布说明。

每台服务器应跟踪四个独立事实：已确认存在漏洞的软件包、已安装替代版本、已重启服务、已验证实际配置。工单中所写的“已打补丁”，通常往往仅仅意味着完成了第二项。

为何此次修复补丁发布如此迅速

Damien Miller 表示，OpenSSH 团队在发布该规避方案的前一天才获悉该问题。他指出近期已有多个 AI Agent 在数小时内独立重新发现漏洞的先例，认为过长的漏洞保密期反而更有利于攻击者。

发布说明还描述了一种转向更频繁发布修复补丁的趋势，而不是将变动积压到定期版本中，同时强调许多由 AI 生成的报告并未展现实际的安全危害，人工分析依然至关重要。

对我们大多数人而言，实际应对方式很简单：关键修复现在可能会在常规维护窗口之外发布。请直接关注厂商公告，并提前确定谁有权执行紧急变更。

以上要点描述的是风险暴露情况及合理的应对措施，并不代表已存在经过证实的针对性攻击活动。

真正的教训：含义迥异的三种表述

“使用 SSH 密钥”、“未设置密码”和“无法通过密码进行身份验证”听上去很相似，但它们描述的是完全不同的概念。第一种是一种使用习惯；第二种是一种数据状态；唯有第三种才是强制生效的安全控制措施，而这一点只有通过对正在运行的服务器进行实际测试才能真正确认。

结语

这是一个影响范围虽小但危害极大的漏洞。大多数 Linux 系统不受其影响，但一台基于 musl 且符合全部四个条件的服务器，可能会允许登录一个本不该拥有密码的账户。请及时更新、重启、配置 PasswordAuthentication no、从外部进行验证、排查日志并修复您的镜像模板。接着，明确写下“仅限密钥”在您团队组织中的确切定义，并对其进行实测检验。

优点

• 风险暴露条件明确具体，各团队可以迅速排除大多数系统。
• 修复后的 Alpine 新版本以及简易的临时缓解措施现已提供。
• 排查检查均使用标准工具，每台服务器仅需数分钟。
• 审查登录活动和账户数据所带来的安全性提升，远超出解决这单个漏洞的范畴。

缺点

• 仅显示“已安装 OpenSSH”的资产清单无法回答是否受影响。
• 一次常规变动（例如添加一个带密码的用户）就可能使原本安全的机器面临风险暴露。
• SSH 配置失误可能会将管理员锁在系统之外。
• 打补丁无法发现也无法撤销此前可能发生过的未经授权访问。

注意事项

本文仅供学习交流之用，基于撰写本文时已公开的安全通告和报道编写。Acme、Rohit、 deploy, backup-admin，主机名和 IP 地址均为虚构的占位符，因此请将其替换为您自己的值。更改 SSH 设置时请保持一个活动会话处于打开状态，仅测试已获得授权的系统，并在依赖这些细节之前根据当前的 OpenSSH 和 Alpine 安全通告或您自身供应商的指引进行核对。

常见问题解答

• 什么是 OpenSSH 10.6p2？ — 这是 2026 年 11 月 5 日发布的一个紧急 Portable OpenSSH 版本，包含针对影响某些基于 musl 的 Linux 系统的登录绕过漏洞的变通方案。
• 每个 Alpine Linux 系统都存在漏洞吗？ — 不是。系统需要运行一个不使用 PAM 检查密码的 SSH 服务端、启用密码身份验证、目标账户具有 * 密码字段，且另一个本地账户拥有 $5$ 或 $6$ 哈希。
• Ubuntu、Debian 和其他 glibc 系统是否受影响？ — 使用 glibc 的 Linux 系统不在所述受影响范围内，非 Linux 平台以及通过 PAM 检查密码的 Linux 系统同样不受影响。
• Alpine Docker 容器是否存在风险？ — 未运行 SSH 服务端的容器不在该攻击路径之内，因此关键在于容器是否实际运行了 sshd。
• PermitRootLogin prohibit-password 能保护我吗？ — 它会阻止直接通过密码登录 root，但并不能阻止攻击者通过其他账户进入并提权，就像 tiny-cloud alpine 账户场景中那样。
• 仅更新软件包就足够了吗？ — 不够。您还必须重启 SSH 服务，因为在此之前旧的服务端会一直在内存中继续运行。
• 如果我今天无法更新，应该怎么做？ — 设置 PasswordAuthentication no，确认生效的设置可使用 sshd -T，并在保持现有会话打开的同时测试密钥访问。
• 我该如何检查是否已经有人利用过此漏洞？ — 搜索 /var/log/messages 中的 Accepted password for 条目（针对不应使用密码的账户），如果无法排除未授权登录，请将该主机视为已被攻破。

标签

#OpenSSH #AlpineLinux #LinuxSecurity #SSH #AuthenticationBypass #Musl #DevSecOps #CloudSecurity #PatchManagement #IncidentResponse