OpenSSH *sshole bug (CVE-2026-123158): check your Alpine servers

On 5 November 2026 OpenSSH released 10.6p2 to fix a bug nicknamed *sshole. On Alpine Linux and other systems built on the musl C library, sshd accepted any password of 257 to 1,024 characters for an account that has no password at all. The bug has been there since 2016. It’s tracked as CVE-2026-123158. If you run sshd on Alpine, check it today. Most Docker images are fine, and the section below explains why.

How a long password opens an account without one

An account without a password usually has * in /etc/shadow. No password hashes to *, so nobody can log in with one. The catch is in musl: its crypt() function gives up on passwords longer than 256 bytes and returns the string *. So sshd hashes the long password, gets * back, compares that with the * in the shadow file, and lets the user in.

A 2016 change in sshd made this reachable. To stop attackers from learning which usernames exist by timing the login, sshd hashes every password attempt, borrowing a salt from another account when needed. The finder, Özgün Kültekin of Wakefield, describes the full history on sshhole.com. The OpenSSH project says in its release notes that it considers the root cause to be outside sshd, but it shipped a workaround anyway.

Who is affected

All of these must be true, according to Alpine:

• sshd runs on musl: Alpine, but also OpenWrt, Buildroot or Yocto builds that use OpenSSH.
• sshd doesn’t use PAM. Alpine’s standard openssh-server package has no PAM.
• Password login is on. That’s the default.
• An account has exactly * as its password field. An account locked with ! is not affected.
• At least one other account has a real password hash ($5$ or $6$).

Root on Alpine has * since version 3.16, but the default PermitRootLogin prohibit-password stops a password login for root. The bigger risk is in Alpine’s official cloud images for AWS and Azure (versions 3.18.11 to 3.24.3). Their alpine user has * and can run doas without a password, so a login there means root. These images are safe on first boot. They become exploitable once any account gets a real password.

There’s also a trap for key-only users. On Alpine, sshd without PAM refuses a key login for an account locked with !. We tested this: the login fails with “account is locked”. The common fix is to change the ! to *, and that’s exactly the setting this bug needs.

Not affected: Debian, Ubuntu, Fedora and other glibc systems, anything that logs in through PAM, Dropbear, and servers with password login turned off.

Are Docker images like python:alpine affected?

Usually not, because most images don’t run an SSH server. We checked the current alpine, python:3-alpine, node:lts-alpine, nginx:alpine, redis:alpine and postgres:alpine images. They all use musl and have root:*, but none has sshd installed. python:3-slim is based on Debian with glibc, so it’s not affected either. The popular linuxserver/openssh-server image turns password login off by default.

You’re at risk if you built your own image with apk add openssh to log in to a container. We checked that too: the package arrives with password login on and without PAM. Rebuild such images with the fixed package, or better, remove sshd from them and use docker exec instead.

How to check your servers

Run these on each Alpine host or container that runs sshd:

# Is password login on, and is PAM off?
sshd -T | grep -iE '^(passwordauthentication|usepam)'

# Accounts with exactly * as password
awk -F: '$2=="*"{print $1}' /etc/shadow

# Accounts with a real password hash
awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

# Installed package version
apk info -v openssh-server

If the first command shows passwordauthentication yes and usepam no, and both lists have names, the server is exposed until you patch. Alpine backported the fix to all branches from 3.16 onward, for example 10.3_p1-r2 on 3.24 and 10.2_p1-r1 on 3.23. The full table is in Alpine’s advisory. Don’t rely on sshd -V: Alpine’s patched packages keep the old upstream version number.

To see whether someone already used it, look for Accepted password in the logs (on Alpine, usually /var/log/messages) for an account that has no password. Any such line means that account was compromised. No attacks have been reported yet, but proof-of-concept code is public.

What to do now

1. Turn off password login. This blocks the bug right away, even before you patch:

   echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
   sshd -t && rc-service sshd restart

   Keep your current session open until you’ve confirmed a new key login works.

2. Update and restart. Run apk upgrade -U -a and then rc-service sshd restart. The running daemon keeps the old code until it restarts.

3. Rebuild images that install openssh or openssh-server, and redeploy them.

4. Check the logs for password logins on accounts without a password.

Keep SSH off the internet

This bug only matters if an attacker can reach your SSH port. If the port isn’t reachable, a bug like this one is a routine update instead of an incident.

• SSH only over a private network. Use Tailscale or WireGuard, and let sshd listen only on that interface or block port 22 everywhere else in the firewall. Tailscale SSH can also replace key management.
• No inbound ports for web apps. Publish public applications through a Cloudflare Tunnel. cloudflared makes an outgoing connection, so the server needs no open ports at all. Put admin pages behind Cloudflare Access.
• Keys only. Set PasswordAuthentication no and KbdInteractiveAuthentication no on every server, also on glibc systems, and limit logins with AllowUsers.
• No sshd in containers. Use docker exec or kubectl exec.
• Check from outside. From another network, for example a phone hotspot, run nc -vz -w 3 <public-ip> 22. If it connects, your SSH port is open to the world.
• Patch automatically, and restart. Security updates only help once the service restarts.