Administrators running sshd on Alpine Linux servers are being told to update openssh and restart sshd right away, since upgrading the package alone leaves the old daemon running.
A flaw in the OpenSSH server lets attackers log in without a password. Those who cannot patch yet can close the hole by setting PasswordAuthentication to no and restarting sshd.
How the OpenSSH Server Flaw Works
An attacker who can reach the SSH port gets in with a single connection that works every time, with no retries. The attacker needs the name of an account whose password field is * (normal for key-only accounts) plus at least one other account with a $5$ or $6$ hash, then sends a password of 257 to 1,024 bytes. One user with a password exposes every account without one.
When built without PAM, sshd hashes each attempt with crypt() and compares it to the stored field, borrowing another account’s salt when that field is too short to hold one. musl’s crypt() returns * as an error indicator for keys over 256 bytes, which exactly matches the stored field of passwordless accounts. OpenSSH 10.6p2 fixes this, and no CVE had been assigned at the time of writing.
Which Alpine Linux Servers Are Affected
Alpine Linux servers are vulnerable when they run openssh-server (built without PAM) or openssh-server-pam with UsePAM no, keep the default PasswordAuthentication yes, hold at least one local $5$ or $6$ hash, and have an account with a * password field. That includes root, shipped as root:* in the base image since about Alpine 3.16.
The default PermitRootLogin prohibit-password shields root unless it is set to yes, but not if another account can become root through doas. Key-only users created with adduser or usermod -p ‘*’, directory users via musl-nscd (nslcd, winbind, sssd), and the tiny-cloud alpine user also count. Every release checked is affected: 3.21 through 3.24, edge, and the older 3.16 to 3.20.
Safe setups include containers not running sshd, systems with PasswordAuthentication no or UsePAM yes, locked accounts (user:! in /etc/shadow), machines with no $-style hash, and cloud-init images, which write PasswordAuthentication no.
Patching the OpenSSH Server
Running apk upgrade -U -a, followed by rc-service sshd restart, applies the fix, which ships in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Fixed builds are edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7 and 3.16 9.0_p1-r6. Although 3.21 reached end of support on 2026-11-01, patched packages go back to 3.16.
For the workaround, root should first confirm key login works and keep the current session open. A drop-in file, /etc/ssh/sshd_config.d/00-no-passwords.conf (read from 3.19 onward), sets PasswordAuthentication no, while a sed command flips every such line in sshd_config, Match blocks included, and saves sshd_config.bak.
Running sshd -t && rc-service sshd restart, then sshd -T | grep -i passwordauthentication, should print passwordauthentication no. Deleting the drop-in and restoring the backup undoes it.
Cloud Images and Spotting Attacks on Alpine Linux Servers
Official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash appears, such as a console password or a user-data account with hashed_passwd, giving attackers a shell as alpine and then root. Instances from earlier point releases need updating or password logins disabled.
Admins should check /var/log/messages for sshd “Accepted password” lines on passwordless accounts and review doas use, new users, files, and authorized keys. If a login cannot be ruled out, the machine should be treated as compromised.
Özgün Kültekin of Wakefield reported the issue. Damien Miller and Darren Tucker of the OpenSSH project delivered the fix and the 10.6p2 release; Timo Teräs helped analyze the bug, and Natanael Copa built and uploaded the updated packages.
