OpenSSH Ships Emergency Fix for Alpine Flaw That Skips Passwords

OpenSSH dropped version 10.6p2 on Nov. 5 as a workaround for a nasty bug that lets attackers log into certain Alpine Linux servers without ever knowing a password. The affected setups run the musl C library with PAM, the password-authentication framework, switched off. OpenSSH developer Damien Miller didn't mince words: disable password authentication, or SSH itself, immediately.

Not everyone is in the crosshairs. Miller said systems on glibc, boxes that lean on PAM for password authentication, and anything not running Linux are unaffected. The real exposure is narrow but sharp: a reachable SSH server with password logins allowed and PAM disabled. Alpine's stock openssh-server package is built without PAM, and its PAM-enabled alternative is also vulnerable when configured with UsePAM no.

Here's how the trick works. The attacker needs the name of a login-eligible account whose stored password field holds an asterisk, and the machine must also carry an account with a SHA-256 or SHA-512 password hash. Type a password between 257 and 1,024 bytes, and the server lets you in. The culprit sits in musl's hashing function, which returns an asterisk to flag an overlong password — a dead ringer for the asterisk stored on accounts with no password. The default block on root password logins still shields root unless an operator has flipped it.

If you only install the patched package, you're not done. Alpine's advisory says operators must restart sshd, because the old server process keeps running. Anyone who can't update right away should set PasswordAuthentication no and restart, but only after confirming key-based login works — and keep the current session open while testing a fresh one. Alpine has pushed fixed images and patched OpenSSH packages for branches back to 3.16. Older branches get backported fixes instead of the upstream 10.6p2 version number.

Cloud images add another wrinkle. Alpine says its unpatched official tiny-cloud images from 3.18.11 through 3.24.3 are safe on first boot, but turn exploitable once a SHA-512 password hash is added — an attacker could slip in as the alpine user and climb to root through its passwordless administrative privileges. Images built from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 carry the fix, and images configured through cloud-init, which turns off SSH password authentication, are fine.

For crypto node, validator and exchange operators, the thing to audit is the remote-login service itself, not just whether a container is Alpine-based. Containers that don't run sshd are unaffected, per Alpine. But the classic setup — a key-only account on a box that still accepts password logins — is exactly where this bites. Alpine's advice for anyone who can't rule out an unauthorized login: treat the machine as compromised, and go read the logs for accepted password logins to accounts that have no password. OpenSSH calls 10.6p2 a workaround and points the finger elsewhere, while musl's lead author and maintainer Rich Felker said his position is that it is not a musl vulnerability.