OpenSSH Patches *sshole Flaw That Lets Attackers Log Into Passwordless Accounts on musl Linux Systems

A decade-old flaw in the way OpenSSH talks to the musl C library lets an attacker log into accounts that are supposed to reject passwords. The fix, OpenSSH 10.6p2, shipped today, Thursday, Nov. 5.

The researcher who found it, Özgün Kültekin of the security firm Wakefield, named the bug *sshole. The name comes from the asterisk at the center of it.

How the bug works

Linux accounts that should never accept a password carry an asterisk in the password field of /etc/shadow. An asterisk is not a valid hash, so no password should match it. Root on Alpine, key-only deployment users and LDAP users are typical examples, according to Kültekin.

The trouble starts with musl's crypt() function. When hashing fails, musl returns an asterisk instead of an error. Hashing fails when the submitted password is longer than musl's 256-byte limit.

In 2016, OpenSSH changed how it handles accounts with no usable hash. The change fixed a username-enumeration flaw, CVE-2016-6210. Since then, sshd runs a hash calculation even for locked accounts, so response times don't reveal which usernames exist.

On musl, that combination backfires. The oversized password makes crypt() return an asterisk, OpenSSH compares it with the asterisk stored for the locked account, and the login succeeds. Passwords between 257 and 1,024 characters work.

The asterisk convention itself goes back to BSD Unix in 1980. A 2012 musl commit chose the asterisk as the "unmatchable hash" returned on failure.

What has to be true to exploit it

The conditions are specific. The server must run OpenSSH on musl, with PAM disabled and SSH password authentication enabled. The attacker needs a valid username for a locked account.

At least one other account must have a valid SHA256 or SHA512 hash. Security firm Check Point said that matters "because sshd borrows that account's salt. Without it, the attack fails."

Systems built on glibc, including Debian, Ubuntu and Fedora, are not affected, nor are systems using PAM. BleepingComputer lists Alpine Linux, OpenWrt, Buildroot and Yocto as musl-based distributions that can be exposed under those configurations. The flaw does not bypass passwords on accounts that have valid hashes.

Root is protected by default. Check Point reported that root accounts are safe under OpenSSH's default PermitRootLogin prohibit-password setting. Reachable accounts with doas or sudo rights can still escalate to root.

Why a narrow bug still matters

Kültekin warns that Alpine's official AWS and Azure cloud images ship a default "alpine" account with passwordless doas privileges. On those images, a successful login can lead straight to root.

The Docker Hub base image for Alpine has more than 1 billion downloads. Alpine is also common in routers, smart TVs and industrial controllers, and many of those devices can't be easily updated, if at all.

Detectify says Shodan lists about 22 million systems with SSH open on port 22. Only a fraction meet the conditions, but testing each one takes a single connection.

Alpine's maintainers said Thursday: "An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries."

OpenSSH's release notes call 10.6p2 "a critical security workaround that affects Linux systems that use the musl libc and PAM disabled." The OpenSSH team says the root cause lies outside OpenSSH, and that it patched the problem there because it is exploitable there.

The patch, and the speed of it

Alpine administrators should run `apk upgrade openssh`. Anyone who can't update immediately can set `PasswordAuthentication no` in the SSH server configuration and restart the service.

OpenSSH maintainer Damien Miller put it bluntly: "stop reading and set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY."

Miller also explained the rush. OpenSSH learned of the problem only the day before. "We have recently observed multiple cases of rapid bug rediscovery by AI agents, sometimes within hours, and so now consider long embargo periods to be a dangerous practice that primarily benefits attackers," he said in a LinkedIn post.

Kültekin says he found the flaw with AI agents that ran about 17,600 authentication tests across different OpenSSH configurations, malformed password hashes and oversized passwords.

To check for exploitation, he advises admins to examine SSH authentication logs for password-based logins on accounts that should not allow them. Researchers have not reported active exploitation so far.

What comes next

Jake Knott, head of threat intelligence at watchTowr, told Cyber Daily that the prerequisites mean many systems won't be affected. The needed combination is musl, no PAM, password login enabled and a locked account with a known username.

But he expects the Alpine AWS and Azure default account to be targeted first. Internet-facing SSH servers already absorb constant brute-force attempts, he said, and adding a very long password to that list costs attackers almost nothing.

"We'd be extremely surprised if we didn't see SSH brute-forcers attempting this by the weekend," Knott said.

The open question is the embedded fleet. Routers, TVs and industrial controllers on musl that can't take a patch will depend on the password-authentication workaround, and no vendor has announced a timeline for updating them.