Home » Security » OpenSSH 10.6p2 Fixes Alpine Linux Password Bypass

OpenSSH 10.6p2 Fixes Alpine Linux Password Bypass

Published 2026-11-06 | Security

Banner showing a terminal icon beside the text OpenSSH password bypass on Alpine Linux, update to 10.6p2

Short answer: OpenSSH released version 10.6p2 on November 5, 2026 to block a login bypass on Linux systems that use the musl C library with PAM turned off, which is how Alpine Linux ships its SSH server. An attacker who knows the name of an account with no password set can log in by sending a very long password. Update OpenSSH and restart sshd, or set PasswordAuthentication no. Ubuntu, Debian, Fedora and other glibc systems are not affected.

The key facts

Item Detail
Fixed in OpenSSH 10.6p2 (November 5, 2026)
CVE None assigned yet
Nickname "*sshole"
Affected sshd on musl Linux with PAM disabled (Alpine by default; OpenWrt, Buildroot and Yocto builds worth checking)
Not affected glibc Linux, non-Linux systems, systems using PAM
Exploited No attacks reported as of November 5
Reported by Özgün Kültekin of Wakefield

OpenSSH's maintainer Damien Miller told anyone running an affected system to "set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY", as quoted by The Hacker News.

How the bypass works

PAM (Pluggable Authentication Modules) is the system many Linux distributions use to check passwords. Without it, sshd checks passwords itself using the crypt() function from the C library.

On musl, crypt() returns the single character * when it fails, including when a password is longer than 256 bytes. Accounts with no password set also store * in /etc/shadow. So an oversized password produces *, which matches the stored *, and sshd lets the attacker in. OpenSSH says the root cause is outside sshd but that it can be blocked there, which is what 10.6p2 does.

Step 1: check whether your server is exposed

According to the Alpine Linux advisory, as reported by The Hacker News, all of these must be true:

  1. The server runs openssh-server built without PAM, or openssh-server-pam with UsePAM no.
  2. PasswordAuthentication is yes (the OpenSSH default).
  3. At least one account has * as its password field, such as root, key-only users, or the alpine user on cloud images.
  4. At least one other account has a password hash starting with $5$ or $6$.

Check the settings and accounts:

sshd -T | grep -i passwordauthentication
grep -E '^[^:]+:\*:' /etc/shadow
grep -E '^[^:]+:\$[56]\$' /etc/shadow

If the first command prints yes and both grep commands print lines, you are exposed.

Step 2: update OpenSSH and restart sshd

On Alpine:

apk upgrade -U -a
rc-service sshd restart

Upgrading the package does not restart the running server, so the restart matters. Alpine point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 include the fix, and fixed packages were also issued for older branches back to 3.16.

Step 3: turn off password logins

If you log in with SSH keys, you do not need password logins at all. Keep your current session open, confirm a key login works in a second window, then set this in /etc/ssh/sshd_config or a file in /etc/ssh/sshd_config.d/:

PasswordAuthentication no

Change every PasswordAuthentication yes line, including any inside Match blocks. Then test and restart:

sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The last command should print passwordauthentication no.

Step 4: look for signs of a break-in

Search the log for password logins to accounts that have no password:

grep "Accepted password" /var/log/messages

A successful password login for root, alpine or a key-only user is a red flag. Also review doas use, new users, new files and authorized_keys entries. The Alpine advisory's guidance is direct: "If you cannot rule out a login, treat the machine as compromised." Rebuild from a clean image and restore from backups.

Common mistakes

  • Updating the package but not restarting sshd, so the old vulnerable process keeps running.
  • Assuming containers are safe. Containers are only safe if they do not run sshd.
  • Setting a console password on a cloud image "just in case". On Alpine tiny-cloud images that creates the $6$ hash the attack needs.
  • Disabling password logins before confirming key logins work, and locking yourself out.
  • Forgetting PasswordAuthentication yes inside a Match block, which overrides the global setting.

Sources

Frequently Asked Questions

Is my Ubuntu or Debian server affected by the OpenSSH 10.6p2 flaw?

No. According to the OpenSSH maintainers, Linux systems built on glibc (such as Debian, Ubuntu and Fedora), non-Linux systems and systems that check passwords through PAM are not affected. The bug needs musl libc with PAM disabled, which is the default on Alpine.

Does the OpenSSH flaw have a CVE number?

Not yet. As of November 5, 2026, The Hacker News reported that no CVE had been assigned. The OpenSSH release notes describe it as a critical security workaround in version 10.6p2.

Is the OpenSSH Alpine bypass being exploited?

No attacks had been reported as of November 5, 2026. The details and the trigger are public, though, so patch or disable password logins now rather than waiting.

Found a mistake or still stuck? Contact us. See how we write and check these guides in our editorial policy, or read about DocumentGuy.