OpenSSH 10.6p2 has been released with a workaround for a critical vulnerability
186 points
• 7 days ago
• Article
Link
OpenSSH 已发布 10.6p2 版本，用于修复一个关键安全漏洞。该缺陷主要影响那些使用 musl libc 、且在密码认证环节不使用 PAM（可插拔认证模块）的 Linux 系统。 Alpine Linux 是这类系统配置的典型代表。该漏洞不影响非 Linux 系统、运行 glibc 的 Linux 系统，以及依赖 PAM 来管理密码认证的 Linux 环境。
强烈建议运行受影响配置的系统管理员立即采取行动。推荐的缓解方案是将配置项 PasswordAuthentication 设置为 no，或在系统尚未完成更新前，直接禁用这些特定系统上的 SSH 。尽管开发人员认为该漏洞的根本原因不在 OpenSSH 之内，但他们仍优先发布迅速的修复版本，以尽量降低潜在被利用的风险。
OpenSSH 团队决定在此次发布中跳过传统的较长保密期。其依据是观察到：AI 代理在漏洞披露后越来越能很快"重新发现"问题，往往只需要数小时。出于这种考虑，维护人员现在认为长期保密期是一种高风险做法，更多是帮助攻击者而非保护用户。
从整体来看，这个安全问题主要是针对负责管理 Linux 系统远程访问的服务器管理员的高关注事件。对于不亲自运维服务器、也不使用远程访问工具的普通个人而言，目前没有必要立即担忧或采取行动。该漏洞高度特定于某一套软件组合，虽然对该领域内的用户风险很高，但对一般终端用户并不构成威胁。
OpenSSH has released version 10.6p2 to address a critical security vulnerability. This flaw specifically impacts Linux systems that utilize musl libc without using PAM, or Pluggable Authentication Modules, for password authentication. Alpine Linux is a notable example of a system configuration that falls into this category. The vulnerability does not affect non-Linux systems, Linux systems running glibc, or Linux environments that rely on PAM to manage password authentication.
System administrators running the affected configurations are strongly urged to take immediate action. The recommended mitigation is to either set the configuration option PasswordAuthentication to no or to disable SSH entirely for those specific systems until they can be updated. While the developers consider the root cause of the bug to exist outside of OpenSSH, they prioritized a swift release to prevent potential exploitation.
The team behind OpenSSH made the decision to bypass traditional long embargo periods for this release. This choice was driven by the observation that AI agents are increasingly capable of rediscovering bugs shortly after they are disclosed, often within just a few hours. Consequently, the maintainers now view long embargoes as a risky practice that primarily serves to assist attackers rather than protect users.
This security issue is essentially a high-level concern for server administrators who manage remote access to Linux systems. For the average individual who does not personally operate a server or use remote access tools, there is no immediate reason for concern or action. The vulnerability is highly specific to a particular software stack, and while it represents a severe risk for those within that niche, it does not pose a threat to general end-users.
237 comments • Comments Link
OpenSSH 在编译时若使用 musl libc，存在一个关键安全漏洞：它没有正确校验身份，从而导致绕过。该漏洞需要特定且非标准的环境配置才能被利用：使用 musl libc 、禁用 PAM 、启用密码验证，并且在 shadow 文件中至少要有一个用户的条目包含 `'*'` 作为占位符。
漏洞的根源在于 musl libc 的 `crypt()` 实现违反 POSIX 标准：失败时它返回一个字符而不是 NULL 。这会误导 OpenSSH，让其把该返回值当成"成功"而非"错误"。
尽管问题本质上出在 musl 库，但 OpenSSH 在尝试缓解计时攻击的过程中又进一步放大了这一缺陷。它在验证阶段向函数传入不同用户的哈希值，无意间让 musl 的错误返回值能够与有效哈希进行比较，从而形成绕过场景。
尽管外界担心该漏洞的严重性，但在很多常见环境中（例如使用 glibc 、 PAM 或 OpenBSD 的场景）本质上并不受影响。像 Dropbear 这样的流行轻量级替代方案也已被证实对这一特定漏洞免疫。
更有效的最终缓解方案是禁用基于密码的身份验证，改用 Public Key Infrastructure 。该做法被普遍视为安全最佳实践，能够显著缩小未经授权访问的攻击面。
WireGuard 也常被推荐作为保护 SSH 访问的更优替代。它在更低的网络层运行，并对未经身份验证的流量进行静默拒绝，从而隐藏服务器存在，降低与 PAM 或传统密码处理等复杂、可配置的身份验证方式相关的风险。
业界仍在努力权衡：一方面是企业对基于密码的 SFTP 访问的传统需求，另一方面是现代要求的"仅限密钥身份验证"的安全要求。这种拉扯往往会让商业环境的安全态势变差，因为客户诉求常常高于内部安全策略。
同时，人们对 Alpine Linux 等特定发行版的可靠性也存在疑虑。批评者指出，过去在处理基础权限配置以及补丁延迟方面出现过问题，反映出部分维护者在基础安全实践上不如更成熟、更严谨的项目。
漏洞之所以能够被快速披露，是因为 AI agents 能在公开报告后的数小时内重新发现漏洞。业内预计，这种变化会重塑行业惯例，可能终结以往为修复准备而设置的长期禁运期。
此次事件凸显了分层软件依赖关系的脆弱性：即便底层库中存在极小的 POSIX 标准偏差，也可能在像 OpenSSH 这样复杂的应用中引发灾难性的安全故障。
社区普遍认为，尽管 musl libc 中的底层错误代表了对标准合规性的重大失误，但依靠成熟的加固与最佳实践，这个漏洞在很大程度上是可以避免的。讨论也反复强调了传统身份验证方法的便利性与受限密钥模型所需安全之间的持续矛盾。最终，这一事件提醒我们：处理身份验证逻辑的复杂依赖关系，尤其需要经过严格测试并遵守既定的 API 契约，才能防止系统性故障。 • A critical security vulnerability exists in OpenSSH when compiled against musl libc, specifically where a failure to properly authenticate allows a bypass. The exploit requires a non-standard configuration: musl libc, disabled PAM, password authentication enabled, and at least one user with a '*' placeholder in their shadow file.
• The vulnerability is rooted in a discrepancy where musl libc's `crypt()` implementation violates POSIX standards by returning a character rather than NULL upon failure. This misleads OpenSSH, which interprets the return value as a success condition rather than an error.
• While the bug is technically within the musl library, OpenSSH contributed to the issue by attempting to prevent timing attacks. By passing a different user's hash into the function during authentication, it inadvertently allowed the musl error return to be compared against a valid hash, creating a bypass scenario.
• Despite concerns about the severity of the bug, many common environments—such as those using glibc, PAM, or OpenBSD—are inherently unaffected. Popular lightweight alternatives like Dropbear are also confirmed to be immune to this specific exploit.
• Disabling password-based authentication in favor of public key infrastructure is considered the definitive mitigation. This configuration is widely viewed as a security best practice that significantly reduces the surface area for unauthorized access.
• WireGuard is frequently recommended as a superior alternative for securing SSH access. By operating at a lower network layer and rejecting unauthenticated traffic silently, it hides the presence of the server and eliminates the risks associated with complex, configurable authentication methods like PAM or traditional password handling.
• The industry continues to struggle with balancing legacy enterprise requirements for password-based SFTP access against the modern security mandate for key-only authentication. These pressures often lead to suboptimal security postures in commercial environments where client demands override internal security policies.
• Concerns regarding the reliability of certain distributions, such as Alpine Linux, have been raised. Critics point to past handling of simple permission configurations and delayed patches as evidence that some maintainers struggle with fundamental security practices compared to more established, rigorous projects.
• The rapid disclosure of this vulnerability was influenced by the emergence of AI agents capable of rediscovering bugs within hours of public reports. This shift is expected to change industry standards, potentially ending long embargo periods that were once intended to allow for prepared fixes.
• The incident highlights the fragility of layered software dependencies, where even minor deviations from POSIX standards in low-level libraries can cascade into catastrophic security failures in complex applications like OpenSSH.
The consensus within the community is that while the underlying bug in musl libc represents a significant failure of standards compliance, the vulnerability is largely avoidable through established hardening practices. The discussion underscores the ongoing friction between the convenience of legacy authentication methods and the necessity of restricted, key-based security models. Ultimately, the episode serves as a reminder that complex dependencies, particularly those that handle authentication logic, require rigorous testing and adherence to established API contracts to prevent systemic failures.