OpenSSH Password Bypass on Alpine: Patch sshd Today

Quick Answer: The OpenSSH password bypass on Alpine Linux lets an attacker log in over SSH with no password when password logins are enabled, the openssh-server package has no PAM (or runs with UsePAM no), and at least one account has a $5$ or $6$ hash. Update openssh and restart sshd, or set PasswordAuthentication no. Upgrading alone isn't enough.

If you run sshd on Alpine, this one needs action today. An attacker who can reach your SSH port can get a shell without knowing any password, in a single connection, and it works every time. Alpine Linux published the security advisory on 2026-11-05, and the fix is available now. The advisory covers every release from 3.16 through 3.24 and edge, so older systems are affected too.

How the OpenSSH Password Bypass Actually Works

When sshd is built without PAM, it checks a password by hashing the attempt with crypt() and comparing the result with the stored password field in /etc/shadow. If the stored field is too short to contain a salt, sshd borrows the salt of another account. That's the first half of the bug.

The second half sits in musl libc. When the key is longer than 256 bytes, musl's crypt() returns the string * as an error indicator. But * is also exactly what the password field holds for every account with no password set. So the "hash" the attacker produces matches the stored field, and the login succeeds.

Here's the cause-and-effect chain in plain terms. The attacker picks an account whose field is *, sends a password between 257 and 1024 bytes, and sshd accepts it. The machine only needs one other account with a $5$ or $6$ hash, which is what makes sshd take the code path that calls crypt(). The advisory notes that OpenSSH 10.6p2 fixes the problem in sshd itself, and the stable-branch Alpine packages carry a patch for the same issue.

Who Is Actually Exposed (The Part Most People Get Wrong)

Here's the counter-intuitive part. The usual advice is that key-only accounts are safe because they have no password. On a vulnerable Alpine box, that's backwards. A * in the password field is the exact value the bypass matches, so those accounts are the targets. Locking an account with ! is the safe state, because ! can't match anything.

The advisory says you're affected if all of these are true:

1. You run the Alpine openssh-server package (built without PAM), or you run openssh-server-pam with UsePAM no. The openssh-server-pam package with UsePAM yes is not affected.
2. PasswordAuthentication is yes. That's the OpenSSH default unless you've changed it.
3. The machine has at least one account with a * password field. Common cases include:
   • root, which ships as root:* in the base image since about Alpine 3.16.
   • Key-only users created with adduser without a password, or with usermod -p '*'.
   • Users from a directory service via musl-nscd (nslcd, winbind, sssd), since they have no shadow entry.
   • The alpine user in official tiny-cloud images.
4. At least one local account has a $5$ or $6$ password hash.

One practical note on root. The default PermitRootLogin prohibit-password keeps root out over SSH. That protection doesn't help if another account that can log in can escalate through doas. Here's where most reviews stop too early: check who can doas to root, not only whether root can log in.

Systems that are not affected include Docker and other container setups that don't run sshd inside the container, systems with PasswordAuthentication no, and accounts whose password field is !, which can't log in by password or key. Cloud images configured through cloud-init are safe as well, since cloud-init writes PasswordAuthentication no.

Option 1: Upgrade openssh and Restart sshd

Upgrading is the real fix. Run these steps on each affected host:

1. Update the package index and upgrade: apk upgrade -U -a
2. Confirm the installed version matches or exceeds the fixed version for your branch.
3. Restart the daemon: rc-service sshd restart

Step 3 is the one people skip. Upgrading the package doesn't restart a running sshd, so the vulnerable process keeps serving logins until you restart it. Verify that the running daemon is the new one before you walk away.

Here are the fixed packages for the branches that matter most. The advisory has the full list, including older branches back to 3.16.

Alpine 3.21.10, 3.22.8, 3.23.8, and 3.24.4 contain the fixed package, so updating to the current point release gets you there in one step. Alpine 3.21 reached end of support on 2026-11-01, but fixed packages were still published for every branch back to 3.16. If you're on an unsupported branch, you should plan a release upgrade, not just a package bump.

Option 2: Disable Password Authentication If You Can't Upgrade

Sometimes a patch window is days away, and the host is already reachable. In that case, turning off password logins closes the hole, because the bypass runs through the password code path. The advisory gives a single command set. Before you run it, confirm that your SSH key login works and keep your current session open until you've tested a new login in a second terminal. If you lock yourself out, you've turned a security fix into an outage.

Run these as root:

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 drop-in file handles releases from 3.19 onward, because Alpine's default sshd_config reads sshd_config.d only from that point. The sed command flips every PasswordAuthentication yes line to no, including lines inside a Match block, and it adds the directive at the top in case no line existed. It also saves the original file as /etc/ssh/sshd_config.bak. The last command should print passwordauthentication no. If it doesn't, don't assume you're safe.

To roll back, delete /etc/ssh/sshd_config.d/00-no-passwords.conf and copy /etc/ssh/sshd_config.bak back over /etc/ssh/sshd_config. Note that disabling passwords is a stopgap. Keep the upgrade on your list, because a host without password auth can still be exposed if someone later re-enables the option.

The Tiny-Cloud Trap

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 and passwordless doas. That makes them safe on first boot, which is exactly why this one bites people. The moment any $6$ hash appears on the machine, the bypass becomes usable.

The advisory lists common ways that happens. An admin sets a console password, or user-data adds a user with hashed_passwd. Then an attacker logs in as alpine and uses doas to reach root. This is the cause-and-effect pattern to watch for on cloud fleets: a safe default plus one ordinary admin action creates the exploit path.

Images built from 3.21.10, 3.22.8, 3.23.8, 3.24.4, and later include the fixed package. Earlier images don't, so update openssh or disable password authentication on every running instance. Patching the image for future launches doesn't touch instances that already exist.

How to Check Whether You Were Already Attacked

Start with the logs. Search /var/log/messages for sshd lines that read Accepted password for an account with no password. That includes alpine, root, or any key-only user. A successful login under one of those names is the signature you're looking for.

grep -E 'Accepted password for (root|alpine)' /var/log/messages

Then widen the net. Review doas usage, recently created users, changes to /etc/shadow, new authorized_keys entries, and files modified recently in system directories. Logs can be incomplete, so a clean grep doesn't prove a clean host. The advisory is direct about this: if you can't rule out a login, treat the machine as compromised. Rebuild it from a known-good image and rotate the keys and credentials it held.

Frequently Asked Questions

What is the OpenSSH password bypass on Alpine Linux?

It's a flaw where sshd accepts a login with no password when an account has a * password field. It affects Alpine systems built without PAM, or running UsePAM no, with password logins enabled and at least one $5$ or $6$ hash on the machine. Alpine published the advisory on 2026-11-05 and fixed packages are available for every release from 3.16 through 3.24.

How do I fix the Alpine OpenSSH password bypass?

Run apk upgrade -U -a, then restart sshd with rc-service sshd restart, because the running daemon keeps the old code until you do. If you can't upgrade, set PasswordAuthentication no in a drop-in file and restart sshd. Test a new key login before you close your existing session.

Why does a password on one account expose other accounts?

The bypass uses one account's real hash to make the code path run, and then it matches the empty * fields of other accounts. The advisory says one user with a password is enough to make every account without one reachable. So removing passwords from the other accounts isn't a reliable defense on its own.

Does disabling root login protect my Alpine server?

Not fully. The default PermitRootLogin prohibit-password blocks root logins over SSH. But another account that can log in and use doas can still reach root, so you need to check your doas rules and your key-only users as well.

Is a Docker container running Alpine affected?

Usually not. The advisory says containers that don't run sshd inside the container aren't affected. If you do run sshd in a container, treat it like any other host and apply the fix.

Here's the single most useful action: run sshd -T | grep -i passwordauthentication on every Alpine host, and fix any host that still shows yes. Try this within the next hour and note the result. Pass this to whoever runs your Alpine fleet, especially if your team uses tiny-cloud images with an alpine user.