OpenSSH Issues Emergency Fix for Flaw Letting Long Passwords Bypass SSH Auth on Alpine Linux

The vulnerability allowed attackers to authenticate to accounts that had no password, including SSH key-only accounts. They needed network access, a valid account name, and a password between 257 and 1,024 bytes. OpenSSH rates the flaw critical because a successful login can provide access to the account and potentially to higher privileges.

The problem appeared when sshd checked passwords without PAM, password authentication was enabled, and another local account had a password. On Alpine, the standard openssh-server package is built without PAM, while password logins are enabled by default. The flaw involves sshd's interaction with musl, Alpine's C library.

OpenSSH released version 10.6p2 to block the attack. Alpine also published fixed packages for supported and older branches back to 3.16. Administrators should update and restart sshd, or immediately set PasswordAuthentication no after confirming key-based access works.

An Alpine server was exposed only when four conditions were all true. It used openssh-server without PAM, or openssh-server-pam with UsePAM no; PasswordAuthentication was yes; at least one account had * as its password field; and another local account had a password hash beginning with $5$ or $6$.

Examples of passwordless accounts included key-only users created without a password, users from a directory service through musl-nscd, root in newer Alpine base images, and the alpine user in official tiny-cloud images. Root remained protected by PermitRootLogin prohibit-password unless that setting was changed.

Containers without sshd, systems with PasswordAuthentication no, cloud-init-configured images, locked accounts containing !, and machines without a $-style password hash were not affected. The issue could also matter on other musl-based systems, including OpenWrt installations using OpenSSH.

The required password was unusually large: between 257 and 1,024 bytes. The attacker also needed network access and the name of an account with no password. According to the advisory, the attack succeeds every time with one connection when the server is vulnerable.

Four conditions had to exist together. The server needed an OpenSSH build without PAM, or a PAM build configured with UsePAM no. PasswordAuthentication had to be yes. A target account needed * as its password field. Finally, another local account needed a password hash beginning with $5$ or $6$.

One password-bearing account could expose every passwordless account on the machine. This made Alpine systems especially important to review because password authentication was enabled by default and its standard openssh-server package was built without PAM. The fix is to update packages and restart sshd, or disable password authentication.

The immediate consequence was unauthorized SSH access to an account that was supposed to accept only key-based authentication or otherwise have no password. The attacker could use the account's permissions, inspect files, create users, or access authorized keys. The article specifically advises reviewing these areas after a possible compromise.

The danger was greatest when the exposed account could become root. Tiny-cloud images from 3.18.11 through 3.24.3 gave the alpine user passwordless doas. Those images were safe at first boot, but became vulnerable after any $6$ password hash appeared, such as when an administrator set a console password. An attacker could then log in as alpine and run doas to become root.

The article reports no attacks using the flaw. Still, administrators should check logs for Accepted password entries involving accounts such as alpine, root, or key-only users. If a login cannot be ruled out, the advisory says to treat the machine as compromised.

If updating is not immediately possible, disabling password authentication stops this attack. The setting is PasswordAuthentication no. It prevents sshd from accepting password-based logins, including the specially crafted password used against passwordless accounts.

First confirm that SSH key login works, and keep the existing session open. Add the setting in an sshd configuration drop-in or adjust the main configuration, then run sshd -t to check the syntax. Restart sshd only after the configuration validates and a new key-based login succeeds.

The advisory says Alpine reads configuration files in /etc/ssh/sshd_config.d from version 3.19 onward. It also recommends checking the effective setting with sshd -T | grep -i passwordauthentication. The expected output is passwordauthentication no. Updating the package and restarting sshd remains the preferred fix.

A password hash is a value produced from a password by a one-way cryptographic function. Systems store the hash, often with a salt and an algorithm marker, rather than the ordinary password. When someone logs in, the system processes the supplied password in the same way and compares the result with the stored value.

This design means the server can test whether a password is correct without needing to keep a readable copy. In the article, Alpine password fields beginning with $5$ or $6$ identify password hashes, while * indicates that no password is set. A ! indicates that an account is locked and was not affected.

Hashes are not perfect protection. Weak passwords can sometimes be guessed and checked against stolen hashes. Modern systems therefore use deliberately expensive password-hashing methods and unique salts. The article specifically identifies $5$ and $6$ hashes as part of this vulnerability's exposure conditions.

During password authentication, SSH receives a username and password, locates that account's stored password information, and checks the supplied password. With PAM enabled, sshd normally sends the request through PAM, which invokes the system's configured password-checking modules. Without PAM, sshd performs the check directly, including through the system crypt() function.

crypt() combines the supplied password with information from the stored hash, such as its algorithm and salt, and returns a value for comparison. On affected Alpine systems, sshd's direct password-checking path interacted incorrectly with musl. That interaction let a password of 257 to 1,024 bytes authenticate to an account whose password field was * when another account had a $5$ or $6$ hash.

This behavior was specific to the affected combination. The article says non-Linux systems, glibc-based Linux systems, and systems checking passwords through PAM were not affected. OpenSSH 10.6p2 changes the behavior to block the attack.