Long Passwords Bypass Alpine SSH Authentication

OpenSSH 10.6p2 fixes a critical authentication flaw that lets an attacker log in to passwordless accounts on affected Alpine Linux servers. The attacker needs network access, a valid account name, and a password between 257 and 1,024 bytes. Alpine has released fixed packages for every branch back to 3.16.

The vulnerable configuration combines four conditions: sshd performs password checks without PAM, PasswordAuthentication is enabled, an account has * in its password field, and another local account has a password hash beginning with $5$ or $6$. Alpine’s standard openssh-server package is built without PAM, and password authentication is enabled by default.

One password-bearing account is enough to expose every otherwise reachable account whose password field contains *. According to Alpine’s advisory, the bypass succeeds on every attempt and requires only one connection.

How an error becomes a valid password

Without PAM, sshd calls the C library’s crypt() function to hash a supplied password and compare the result with the stored password field. An account represented by * has no usable salt, so sshd borrows the salt from another account with a real hash.

For $5$ and $6$ hashes, musl rejects passwords longer than 256 bytes. Its crypt() implementation returns * to represent that error. sshd then compares the returned value with the target account’s stored field. Both are *, so authentication succeeds. OpenSSH permits passwords as long as 1,024 bytes, which defines the upper end of the exploitable range.

The interaction spans several old defensive changes. Musl began returning an unmatchable hash instead of NULL for failed crypt() calls in 2012 because many callers did not handle failure. Its 256-byte limit was added later that month to reduce denial-of-service risk. OpenSSH introduced salt borrowing in 2016 while addressing the username-enumeration issue CVE-2016-6210. Reporter Özgün Kültekin says the bypass has existed since that OpenSSH change.

OpenSSH 10.6p2 refuses a match when the stored password field is shorter than four characters. The project describes this as a workaround and places the root cause outside sshd. Alpine’s stable packages contain a patch for the same issue.

Which Alpine systems need attention

Passwordless key-only users created with adduser, accounts changed with usermod -p '*', and directory-service users without shadow entries can be exposed. Alpine’s base image has shipped with root:* since about version 3.16. The default PermitRootLogin prohibit-password setting prevents direct password access to root, unless an administrator has set PermitRootLogin yes.

Privilege paths still matter. An exposed account that can invoke doas may provide root access. Tiny-cloud images from 3.18.11 through 3.24.3 assign passwordless doas access to the alpine user. Those images start in a safe state, but become vulnerable once any $6$ password hash is added, such as when an administrator sets a console password. An attacker can then authenticate as alpine and become root through doas.

Containers without sshd, systems with PasswordAuthentication no, and cloud images configured through cloud-init are unaffected. Accounts locked with ! are also unaffected, as are machines with no $-style password hash.

Other musl-based platforms may have the same dangerous combination. Kültekin specifically identifies OpenWrt, Buildroot, and Yocto as systems to inspect. OpenWrt uses Dropbear by default, and Dropbear is unaffected. An OpenWrt host matters here only if an administrator installed OpenSSH server.

Patch, restart, and inspect

On Alpine, install the fixed packages and restart sshd:

apk upgrade -U -a
rc-service sshd restart

The restart is required because upgrading the package does not replace the running sshd process. Alpine point releases 3.21.10, 3.22.8, 3.23.8, and 3.24.4 include the corrected package. Unsupported branches from 3.16 through 3.21 also received fixes. Self-built OpenSSH deployments should move to 10.6p2.

If an update cannot be applied immediately, first verify that key authentication works and keep the current session open while testing a new connection. Set PasswordAuthentication no, validate the configuration with sshd -t, restart sshd, and confirm the effective value:

sshd -T | grep -i passwordauthentication

The result should be passwordauthentication no. Check both the main configuration and any Match blocks or drop-in files that may override it.

Review /var/log/messages for sshd entries reporting Accepted password for alpine, root, or any key-only account. On exposed hosts, inspect doas activity, newly created users, changed files, and authorized_keys. Alpine advises treating the machine as compromised when an unauthorized login cannot be ruled out.

No exploitation had been reported when the fix was released, and no CVE identifier had been assigned. OpenSSH’s Damien Miller advised affected operators to disable password authentication or SSH immediately.