Decade-Old OpenSSH Flaw Lets Oversized Passwords Unlock Password-Disabled Linux Accounts

A long-lived bug in a trusted tool

Security researcher Bruce Schneier has drawn attention to a newly disclosed vulnerability↗ involving OpenSSH, the widely used tool for remote server access, and musl, a lightweight C library found in some Linux distributions. The flaw, nicknamed "sshole", is described as having been present in the code for roughly a decade.

According to the reports, the problem lets an attacker sign in to certain Alpine Linux and other musl-based Linux accounts that are configured to refuse password authentication↗. The trick is surprisingly simple: submitting an oversized password, meaning one longer than 256 bytes.

What is affected

• Software involved: OpenSSH combined with the musl C library.
• Systems named: Alpine Linux and other musl-based Linux systems.
• Accounts at risk: Accounts set up so that password login is blocked, a common approach for service accounts or for users who should only sign in with SSH keys.

The source article does not list specific software versions or a patch↗, so readers should consult their distribution's advisories for current details.

How the flaw appears to work

The source article itself does not explain the mechanism. A reader comment on it, which should be treated as unverified, offers this summary. Locked accounts are often given a placeholder value such as * instead of a real password hash. Musl's password-hashing↗ function is said to return that same * character when hashing fails, and an oversized password can trigger such a failure. OpenSSH then compares the returned value with the stored placeholder, finds a match, and treats the login as valid.

If that description is accurate, this is a classic example of an error result being mistaken for a legitimate answer. The check never verifies a real password; it just sees two identical values.

Why it matters

Disabling password logins is a standard hardening↗ step. Administrators rely on it to stop brute-force guessing and credential stuffing↗. A flaw that bypasses that protection undermines an assumption many people never think to test. Alpine Linux and musl are especially popular in containers and lightweight or embedded environments, so affected systems may be less visible than traditional servers.

The report also shows how a bug can sit unnoticed in widely reviewed software for years. Interactions between two separate components, here an application and a system library, can create gaps that neither project would see in isolation.

What readers and administrators should do

• Identify exposure: Check whether any of your servers, containers or devices run Alpine or another musl-based distribution and expose SSH.
• Watch for updates: Follow your distribution's security advisories and apply OpenSSH or musl updates as soon as they are available.
• Limit SSH exposure: Restrict SSH to trusted networks, VPNs or bastion hosts rather than the open internet.
• Disable password authentication at the server level: Where possible, turn it off in the SSH daemon configuration instead of relying only on locked account entries, and use key-based or other strong authentication.
• Review logs: Look for unusual SSH login attempts, particularly with very long passwords, and for successful logins to accounts that should never use passwords.
• Prune accounts: Remove unused accounts and limit which users may log in over SSH.

The bigger picture

Nothing here suggests panic is warranted, but it is a good reminder that layered defences matter. Network restrictions, minimal accounts, monitoring and prompt patching all reduce the damage when a single control fails unexpectedly.

Further technical details are available on the researchers' dedicated page and in coverage by BleepingComputer, Slashdot and Ars Technica, all linked from the original post.

Source: Schneier on Security