If you run sshd on Alpine Linux, Alpine’s advisory opens with the instruction rather than the analysis: update openssh and restart sshd, because upgrading the package alone does not replace the running daemon.

Upstream shipped Portable OpenSSH 10.6p2 on 5 November with “a critical security workaround that affects Linux systems that use the musl libc and PAM disabled.”

What the attack does

Alpine does not hedge. “An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.” The attacker needs the name of an account whose password field is *, and one other account on the machine carrying a $5$ or $6$ password hash. Then comes a long password, in Alpine’s range “257 to 1024 bytes”. “One user with a password is enough: it makes every account without one reachable.”

Why it works

Alpine explains the mechanism. Without PAM, sshd hashes the attempt with crypt() and compares the result to the stored field. Where that field is too short to contain a salt, sshd borrows the salt belonging to another account. musl’s crypt() returns the string * as an error indicator once the key is longer than 256 bytes, and * is exactly what an account with no password stores, so the comparison matches.

Upstream draws the boundary differently. It calls the flaw “exploitable through sshd(8)”, then says “We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.” What 10.6p2 ships is a workaround in sshd, not a change to musl.

Are you affected

Three conditions have to hold together. You run Alpine’s openssh-server, built without PAM, or openssh-server-pam with UsePAM no. PasswordAuthentication is yes, the OpenSSH default. And the machine has an account whose password field is * alongside one local account with a $5$ or $6$ hash.

root ships as root:* from about Alpine 3.16, though OpenSSH’s default PermitRootLogin prohibit-password keeps root out unless it is set to yes, and that does not help when another account that can log in can become root through doas. Key-only users, directory-service accounts through musl-nscd and the alpine user in tiny-cloud images carry that field too.

The not-affected list matters as much: containers that do not run sshd, PasswordAuthentication no, openssh-server-pam with UsePAM yes, locked accounts carrying an exclamation mark in the shadow field, systems with no $-style hash, and cloud-init images, which write PasswordAuthentication no.

Fix it, then restart it

apk upgrade -U -a
rc-service sshd restart

“Upgrading the package does not restart a running sshd, so you must do it after.” That restart is the step people skip. Fixed versions run from 10.6_p2-r0 on edge back to 9.0_p1-r6 on 3.16, with 10.3_p1-r2 on 3.24 among them, and the point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 carry the fixed package.

If you cannot update yet

Set PasswordAuthentication no in your sshd configuration and restart sshd, and “Either one closes the hole.” Make sure key login works first, and keep your current session open until a new login has been tested.

To check whether it was used, the advisory points at /var/log/messages: sshd lines reading “Accepted password” for an account with no password, such as alpine, root or a key-only user, then a review of doas use and new users, files and authorised keys.

No CVE, and a faster cadence

Readers will look for an identifier and there is none: “No CVE identifier had been assigned at the time of writing.” Upstream’s notes explain the shape of this release: many reports now arrive as AI findings, which the project welcomes alongside human triage, and it will ship more frequent releases rather than batching fixes.

Sources: the OpenSSH 10.6p2 release notes and Alpine’s advisory.