OpenSSH Password Bypass Lets Hackers Log In to Alpine Linux Devices Without a Password

A new OpenSSH flaw lets an attacker log into certain Linux devices without knowing the password at all. Researchers have nicknamed the issue “sshhole”, and the devices in the firing line run Alpine Linux, the tiny distribution that powers a huge share of Docker containers, routers, and single-board computers. Here is how the bypass works, which devices are affected, and exactly how to patch yours.

What Is the OpenSSH Password Bypass?

The problem sits at the intersection of two design choices. Alpine Linux uses musl libc instead of the more common glibc, and its OpenSSH package is built without PAM (Pluggable Authentication Modules). On that combination, OpenSSH’s password checking can be tricked into accepting a login it should reject.

According to security researchers reporting on the flaw, the bypass works under specific conditions:

• The target account has a password hashed with SHA-256-crypt or SHA-512-crypt, including the usual salt, or
• The account is passwordless and marked with “*” in /etc/shadow, which is common on locked system accounts
• The attacker sends a password string longer than 256 characters during authentication

When those conditions line up, authentication succeeds without the attacker knowing the real password. The root account is not affected under default settings, because OpenSSH ships with PermitRootLogin set to prohibit-password. Regular user accounts with password login enabled are the exposure.

Worse, the bypass needs no special file, no crafted image, and no man-in-the-middle position. A plain SSH login attempt with the oversized password is enough, which puts this bug in the category defenders patch on sight.

Which Devices Are Affected?

The short version: anything running musl-based OpenSSH without PAM. That includes:

• Alpine Linux servers, desktops, and containers (musl is the default libc)
• Embedded firmware built with OpenWrt, Buildroot, or Yocto, where musl and PAM-free OpenSSH are common choices
• Docker images based on Alpine, the most popular container base family on Docker Hub

Mainstream glibc distributions such as Ubuntu, Debian, and Fedora use PAM by default and are not affected by this bypass as described. At the time of reporting, no CVE had been assigned yet, which makes tracking the fix harder than usual. The fix itself is in OpenSSH 10.6p2, and Alpine has shipped updated openssh packages.

Why This Matters at Scale

Alpine Linux sounds niche until you count what it runs. Alpine base images on Docker Hub have passed one billion downloads. Add in routers, NAS boxes, IoT gateways, and lab machines, and the attack surface gets uncomfortable.

Research from security firm Detectify, covered by Ars Technica, counted on the order of 22 million SSH servers visible to internet scanners. Only a slice of those run musl-based builds, but a slice of 22 million is still a lot of devices. Anyone can find them, and the bypass needs nothing more than a login attempt with an oversized password.

How the 256-Character Trick Works

The exact internals are still being documented, but the reported mechanics are straightforward. When OpenSSH checks a password, it hashes the input and compares it against the stored hash. On PAM-less musl builds, an extremely long input (over 256 characters) hits an edge case in that comparison path, and the check passes when it should fail.

The two account types at risk make sense in that light. A SHA-256 or SHA-512 crypt hash with a salt gives the buggy path something concrete to miscompare, while a “*” entry in /etc/shadow represents a locked or passwordless account that the same code mishandles. Attackers do not need to craft anything complex beyond the long password string, which is why patching quickly matters even though no CVE number exists yet.

How to Check If You Are Affected

1. Check your libc. Run ldd --version. If the output mentions musl, you are on the affected family. Glibc systems print a version starting with “GLIBC”.
2. Check your OpenSSH version. Run ssh -V. Anything older than 10.6p2 on a musl system should be treated as unpatched.
3. Check your distribution. On Alpine, run apk info openssh to see the installed package version.
4. Check password policy. If you rely on password authentication over SSH on any of the affected builds, you are exposed until you patch.

How to Protect Your Systems

1. Update OpenSSH first. On Alpine: apk update && apk upgrade openssh, then restart the sshd service. For OpenWrt or custom firmware, check with your vendor for a rebuilt image.
2. Turn off password authentication. Set PasswordAuthentication no in /etc/ssh/sshd_config and reload sshd. Key-only login removes the bypass entirely. Verify with sshd -T | grep passwordauthentication.
3. Keep root locked down. Leave PermitRootLogin at prohibit-password, or disable root SSH login completely.
4. Restrict who can reach port 22. Firewall allowlists, VPN-only access, or a tool like fail2ban shrink the window to nothing.
5. Audit your accounts. Look through /etc/shadow for accounts with “*” entries that somehow accept logins, and remove SSH access for accounts that do not need it.
6. Watch for the CVE. No CVE has been assigned yet, so track the OpenSSH release notes and your distribution’s advisories for follow-up fixes.

What is the sshhole OpenSSH vulnerability?

“Sshhole” is the nickname for a password bypass in OpenSSH on musl-based systems such as Alpine Linux. Sending a password longer than 256 characters can authenticate an account without knowing its password. The fix ships in OpenSSH 10.6p2.

Is Ubuntu or Debian affected by the OpenSSH password bypass?

Not as described. The bypass targets OpenSSH builds without PAM running on musl libc, which is the Alpine Linux and embedded firmware setup. Ubuntu, Debian, and Fedora use PAM by default. Keeping OpenSSH updated everywhere is still good practice.

How do I update OpenSSH on Alpine Linux?

Run apk update && apk upgrade openssh as root, then restart sshd. Verify with ssh -V that you are on 10.6p2 or newer.

Is the root account affected by the OpenSSH password bypass?

Not under default settings. OpenSSH ships with PermitRootLogin set to prohibit-password, which blocks password logins for root. The risk is to regular user accounts that allow password authentication.