OpenSSH ‘SSHole’ Bypass: Patch Alpine Linux and Restart sshd

OpenSSH has issued an urgent fix for a password-authentication bypass affecting Linux systems that use musl libc without PAM, a combination common on Alpine Linux. On a vulnerable server, an attacker who knows the name of a passwordless account can log in with a password between 257 and 1,024 characters.

The flaw is tracked as CVE-2026-123158. OpenSSH released version 10.6p2 on November 5, and Alpine has backported the fix across supported and several older release branches. Alpine’s advice is direct: update the package and restart sshd.

Who is actually affected

This is not a universal OpenSSH flaw. An installation is vulnerable only when several conditions line up:

• The SSH server runs on Linux with musl libc.
• OpenSSH is built or configured without PAM. Alpine’s standard openssh-server package fits this condition; openssh-server-pam is affected when UsePAM no is set.
• PasswordAuthentication yes is effective for the target account.
• The target account has * in its /etc/shadow password field, as is common for key-only accounts.
• At least one local account has a SHA-256 or SHA-512 crypt hash beginning with $5$ or $6$.

Docker and Kubernetes users are not affected merely because an image is based on Alpine. Most containers do not run sshd. Systems with password authentication disabled, PAM enabled or password fields locked with ! are also outside the vulnerable path.

Alpine’s official tiny-cloud images deserve extra attention. Images from 3.18.11 through 3.24.3 include an alpine user with a * password field and passwordless doas. They are safe on first boot because cloud-init disables password authentication. They can become exploitable if an administrator later enables password logins and creates any local $6$ password hash. A successful login as alpine can then become root through doas.

How a long password turns into a match

The bypass comes from the interaction between OpenSSH and musl’s crypt() function. Without PAM, sshd passes the submitted password to crypt() and compares the result with the stored password field.

For a password longer than 256 bytes, musl returns a single asterisk as an error marker. That same character is stored for accounts that are not supposed to have a usable password. The failed hash operation therefore produces *, the comparison sees * in both places, and authentication succeeds.

Alpine’s advisory says the attack needs one connection, works reliably and does not require password guessing. OpenSSH 10.6p2 rejects the invalid short hash result before the comparison can authorize the session.

Patch Alpine and restart sshd

On Alpine, install all available upgrades:

apk upgrade -U -a
rc-service sshd restart

The restart is essential. Updating the package changes files on disk but does not replace an already running sshd process.

Alpine lists these fixed OpenSSH packages:

Branches 3.21 and older are outside regular support, even though Alpine published OpenSSH fixes back to 3.16. Operators should treat the patch as an immediate containment step and plan an operating-system upgrade.

Mitigation when an update must wait

Disable password authentication after confirming that key-based access works. Keep the current administrative session open while testing a second login so a configuration mistake does not lock you out.

On Alpine 3.19 and later, create a drop-in:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

The final command should print passwordauthentication no. Older Alpine releases do not read the drop-in directory by default, so edit /etc/ssh/sshd_config directly, validate with sshd -t and restart the daemon.

Check the effective configuration rather than relying on one line in the main file. Include directives and Match blocks can change authentication settings for particular users or network ranges.

How to look for unauthorized access

Review /var/log/messages for an Accepted password for entry involving alpine, root or another account that should be key-only. Correlate those entries with source addresses, session commands and doas activity.

Also inspect recently created users, modified authorized_keys files, scheduled jobs, startup scripts and unexpected processes. If an internet-reachable host met all the vulnerable conditions and its logs cannot rule out a successful login, rebuild it from a trusted image and rotate credentials available to that machine.

The OpenSSH 10.6p2 release notes call the change a critical security workaround. They also say the project is receiving more AI-assisted vulnerability reports and will make releases more frequently when independent researchers may be finding the same bugs. For administrators, that makes package monitoring and daemon restarts part of the fix, not an afterthought.