Alpine Linux SSH bug lets attackers log in with no password

Alpine Linux dropped a security advisory on Thursday with a blunt warning: if you're running sshd on Alpine, update openssh and restart the daemon. An attacker who can reach your SSH port can log in without knowing a single password. One connection, every time, no retries needed.

The bug lives in sshd builds that skip PAM. Password checks hash the attempt with crypt() and compare it to the stored password field, according to the advisory. For accounts whose stored field is too short to hold a salt, sshd borrows a salt from another account — and musl's crypt() returns the string * as an error indicator when the key runs past 256 bytes. That * is exactly what sits in the password field of every account with no password set, so the hash matches and the door swings open.

The attacker needs two things: the name of an account with a * password field (standard for key-only accounts), and at least one other account on the machine carrying a $5$ or $6$ hash. Then they fire off a long password — 257 to 1024 bytes. A single user with a password is enough to make every passwordless account reachable. No CVE had been assigned at the time of writing, and the technical details are in the OpenSSH 10.6p2 release notes.

Every Alpine release checked — 3.21 through 3.24 and edge — carries the flaw, along with the older 3.16 to 3.20 releases that no longer get regular updates. Alpine published fixed packages all the way back to 3.16 anyway. The patched versions are 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Upgrading alone isn't enough: you have to restart sshd with rc-service sshd restart, because installing the package doesn't touch a running daemon.

Can't update right now? Kill password logins instead. Set PasswordAuthentication no in your sshd config and restart sshd — either fix closes the hole. Alpine's advisory walks through a drop-in file for the default config (read from 3.19 onward), a sed command that flips every PasswordAuthentication line to no and saves a backup, and the two commands to verify and restart the daemon. The payoff: passwordauthentication no. Test a fresh login before you close your current session, and make sure key auth works first.

The official tiny-cloud images — qcow2, VHD and AMI artifacts from 3.18.11 through 3.24.3 — ship an alpine user with a * password field and passwordless doas. They're safe on first boot, but the moment any $6$ hash lands on the machine (an admin setting a console password, user-data adding a user with hashed_passwd), they're exploitable. An attacker gets a shell as alpine, then doas walks them to root. Images from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later include the fix; anything earlier needs an openssh update or password auth switched off on every running instance. If you can't rule out a login, treat the box as compromised — and start by grepping /var/log/messages for sshd lines reading Accepted password for an account that has no password. Özgün Kültekin of Wakefield reported the bug; Damien Miller and Darren Tucker of OpenSSH shipped the 10.6p2 release with the fix, and Timo Teräs and Natanael Copa helped analyze and package it.