Alpine Linux Security advisory: OpenSSH-server password authentication bypass

2026-11-05

If you run sshd on Alpine Linux, update openssh now and restart sshd. Upgrading the bundle solitary does not substitute the operating daemon.

If you cannot update yet, at smallest disable password logins: set PasswordAuthentication no in your sshd configuration and restart sshd. Either one closes the hole.

What is the problem?

An attacker who can attain your SSH harbor can log in without knowing any password. It takes one connection, plant all time, and needs no retries.

The attacker needs the name of an document whose password site is * (an document alongside no password set, which is normal for key-only accounts), and needs the device to have at smallest one another document alongside a $5$ or $6$ password hash. The attacker afterward sends a extremely lengthy password (257 to 1024 bytes). One person alongside a password is enough: it makes all document without one reachable.

Details are in the OpenSSH 10.6p2 release notes. No CVE identifier had been assigned at the period of writing.

Who is affected?

You are affected if all of the following are true:

• You run the Alpine openssh-server package, which is built without PAM, or you run openssh-server-pam alongside UsePAM no. (openssh-server-pam with UsePAM yes is not affected.)
• PasswordAuthentication is yes (the OpenSSH default, unless you changed it).
• The device has an document whose password site is *. This includes:
  • root, which ships as root:* in the basis depiction since concerning Alpine 3.16. OpenSSH’s default PermitRootLogin prohibit-password protects root, so root is lone reachable if PermitRootLogin yes is set. That does not assistance if another document that can log in is capable to rotate into root, for example through doas.
  • Any key-only person created alongside adduser without a password, or with usermod -p '*'.
  • Users coming from a directory assistance through musl-nscd (nslcd, winbind, sssd), since they have no shade entry.
  • The alpine person in the authoritative tiny-cloud images (see below).
• At smallest one local document has a $5$ or $6$ password hash.

Affected releases: all Alpine publish we checked, 3.21 through 3.24 and edge, and the older releases that no longer obtain regular updates (3.16 to 3.20).

Who is not affected?

• Docker and another receptacle users that do not run sshd in the container.
• Systems alongside PasswordAuthentication no.
• Systems using openssh-server-pam alongside UsePAM yes (with UsePAM no you are affected).
• Locked accounts: those alongside ! as the password site in /etc/shadow (a row starting user:!:). They cannot log in alongside a password or a key.
• Systems anywhere no document has a $-style password hash.
• Cloud images configured through cloud-init, which writes PasswordAuthentication no.

How can I fix it?

1. Update

apk upgrade -U -a 

Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4 merge the fixed bundle (see the release announcement). The fixed bundle versions are:

Restart sshd following upgrading (rc-service sshd restart). Upgrading the package does not restart a operating sshd, so you must do it after.

2. If you cannot update: disable password authentication

Before you start, create certain your SSH key login works, and keep your current session open until you have tested a new login.

Run these as root. The archetypal two commands create a drop-in file. Alpine’s default sshd_config says that directory from 3.19 onward; older releases ignore it. The sed command changes yes to no on every PasswordAuthentication row in /etc/ssh/sshd_config, any the spacing, including lines inner a Match block. It additionally adds PasswordAuthentication no at the top of the file, for the case anywhere there was no specified line, and saves the first as /etc/ssh/sshd_config.bak. The final two commands check the configuration, restart the daemon, and display the result:

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 final command should imprint passwordauthentication no. To undo, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and copy /etc/ssh/sshd_config.bak rear complete /etc/ssh/sshd_config.

Cloud images (tiny-cloud)

The authoritative tiny-cloud images (the qcow2, VHD and AMI artifacts) from 3.18.11 through 3.24.3 container an alpine person alongside a * password site and passwordless doas. They are harmless on archetypal boot. They rotate into exploitable as soon as any $6$ hash exists on the machine, for example whenever an admin sets a console password, or user-data adds a person alongside hashed_passwd. An attacker then gets a casing as alpine and can use doas to rotate into root.

Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4 and afterward contain the fixed package. Images from before item releases do not, so on all running instance, update openssh or disable password authentication.

Releases that are no longer supported (3.21 and older)

These releases have the identical bug. 3.21 reached its end of assistance on 2026-11-01, but we have published fixed packages for all publish all the way back to 3.16.

How do I cognize if I was attacked?

Look in /var/log/messages for sshd lines study Accepted password for an document that has no password (alpine, root, or any key-only user). Review doas use and lately created users, records and authorized keys on exposed machines. If you cannot regulation out a login, treat the device as compromised.

How could this happen?

When sshd is built without PAM, it checks a password by hashing the attempt with crypt() (the C archive function that turns a password into its stored hash) and comparing the outcome to the stored password field. For an account whose stored site is too abbreviated to merge a sodium chloride (the random prefix of a hash), sshd borrows the sodium chloride of another account.

musl’s crypt() returns the cord * as an error indicator whenever the key is over 256 bytes long. * is additionally exactly what the stored site contains for every document alongside no password, so the “hash” matches and the login succeeds.

OpenSSH 10.6p2 avoids the issue in sshd. The stable-branch packages above carry a place for the identical problem.

Credits

Reported by Özgün Kültekin of Wakefield. Thanks to Damien Miller and Darren Tucker of the OpenSSH project for the fix and the 10.6p2 release, to Timo Teräs for assistance analyzing the issue, and to Natanael Copa, who built and uploaded the updated packages.