Security advisory: openssh-server password authentication bypass

Key points

Alpine Linux has published a security advisory for a flaw in its OpenSSH server packages. Anyone who can reach the SSH port can log in to accounts that have no password set, using one connection and no retries. Fixed openssh packages are available for edge and for every release back to 3.16, and sshd must be restarted after the upgrade.

How the attack works

• The target account must have * as its password field, which is normal for key-only accounts.
• At least one other local account must have a $5$ or $6$ password hash.
• The attacker sends a password of 257 to 1024 bytes.
• A single user with a password is enough to expose every passwordless account on the machine.
• No CVE had been assigned when the advisory was written. Details are in the OpenSSH 10.6p2 release notes.

Who is affected

• You are affected only if all of the conditions below apply.
• The server runs openssh-server, which Alpine builds without PAM, or openssh-server-pam with UsePAM no.
• PasswordAuthentication is yes, which is the OpenSSH default.
• The machine has at least one account whose password field is *, such as:
• root, which ships as root:* since roughly Alpine 3.16. The default PermitRootLogin prohibit-password protects root unless PermitRootLogin yes is set, but any exposed account that can become root (for example through doas) still leads to root.
• Key-only users created with adduser without a password, or with usermod -p '*'.
• Directory-service users served through musl-nscd (nslcd, winbind, sssd), because they have no shadow entry.
• The alpine user in the official tiny-cloud images.
• At least one local account has a $5$ or $6$ hash.
• Every release the project checked is affected: 3.21 to 3.24 and edge, plus the older 3.16 to 3.20.

Who is not affected

• Docker and other container users who do not run sshd inside the container.
• Systems with PasswordAuthentication no.
• openssh-server-pam with UsePAM yes.
• Locked accounts, meaning those with ! in the password field of /etc/shadow. They cannot log in with a password or a key.
• Machines with no $-style password hash at all.
• Cloud images configured through cloud-init, which sets PasswordAuthentication no.

How to fix

• Upgrade, then restart the daemon. Upgrading the package does not restart a running sshd.

apk upgrade -U -a
rc-service sshd restart

• Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix.
• Fixed openssh versions by branch:
• 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
• 3.16: 9.0_p1-r6
• 3.21 reached end of support on 2026-11-01. Even so, fixed packages were published for every branch back to 3.16.

Workaround if you cannot upgrade yet

• Turning off password authentication also closes the hole.
• Before you start, confirm that key login works, and keep your current session open until a new login has been tested.
• Run the commands below as root:
• The drop-in file is read by Alpine's default sshd_config from 3.19 on; older releases ignore it.
• The sed command switches every PasswordAuthentication line in /etc/ssh/sshd_config to no, including lines inside Match blocks.
• It also adds a PasswordAuthentication no line at the top and saves the original file as /etc/ssh/sshd_config.bak.

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

• The last command should print passwordauthentication no.
• To revert, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and copy /etc/ssh/sshd_config.bak back over /etc/ssh/sshd_config.

Cloud images (tiny-cloud)

• The official qcow2, VHD and AMI images from 3.18.11 through 3.24.3 ship an alpine user with a * password field and passwordless doas.
• These images are safe on first boot.
• They become exploitable once any $6$ hash exists on the machine, for example after an admin sets a console password or user-data adds a user with hashed_passwd. An attacker then gets a shell as alpine and can use doas to become root.
• Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and later contain the fix.
• Instances started from earlier images must be upgraded, or must have password authentication disabled.

Checking for compromise

• Search /var/log/messages for sshd "Accepted password for" entries on accounts without a password, such as alpine, root or key-only users.
• On exposed machines, review doas use and any recently created users, files and authorized keys.
• If a login cannot be ruled out, treat the machine as compromised.

Cause

• Without PAM, sshd checks a password by hashing it with crypt() and comparing the result to the stored field. For accounts whose field is too short to hold a salt, it borrows another account's salt.
• For keys over 256 bytes, musl's crypt() returns * to signal an error. That string matches the stored field of every passwordless account, so the login succeeds.
• OpenSSH 10.6p2 fixes this in sshd, and the stable-branch packages carry a patch for the same problem.

Credits

• The flaw was reported by Özgün Kültekin of Wakefield.
• Damien Miller and Darren Tucker of OpenSSH wrote the fix.
• Timo Teräs helped with the analysis, and Natanael Copa built and uploaded the packages.

Summary by DistroNews, based on the original post.