Home » Security » OpenSSH 10.6p2 Fixes Alpine Linux Password Bypass
OpenSSH 10.6p2 Fixes Alpine Linux Password Bypass
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:
- The server runs
openssh-serverbuilt without PAM, oropenssh-server-pamwithUsePAM no. PasswordAuthenticationisyes(the OpenSSH default).- At least one account has
*as its password field, such asroot, key-only users, or thealpineuser on cloud images. - 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 yesinside aMatchblock, 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.