Security researcher **Ozgun Kultekin** has unveiled a significant vulnerability affecting **OpenSSH** implementations on Linux distributions that utilize the **musl** C library. Dubbed "*sshole," this flaw permits unauthorized access to accounts configured to disallow password authentication, simply by providing an excessively long password. ### The Technical Breakdown of *sshole The vulnerability primarily impacts systems like **Alpine Linux**, **OpenWrt**, **Buildroot**, and **Yocto**, specifically when **OpenSSH** is configured without **PAM** authentication. The root cause lies in a 2016 patch for **CVE-2016-6210**, a username enumeration vulnerability. This patch modified **OpenSSH** to perform password hashing even for accounts without valid password hashes (e.g., those with an asterisk `*` in `/etc/shadow` to block logins), aiming to prevent attackers from inferring valid usernames based on differing response times. However, the **musl** C library's `crypt()` function returns an asterisk `*` when password hashing fails, including when the submitted password exceeds its 256-byte buffer limit. This creates a dangerous scenario: an attacker submits an oversized password, causing `crypt()` to return `*`. **OpenSSH** then compares this `*` against the account's stored `*` (signifying no password authentication), leading to a successful login. Crucially, this flaw does not bypass valid passwords on accounts that are genuinely protected by them. ### Conditions for Exploitation Exploitation of the "*sshole" vulnerability requires a specific set of circumstances: * **OpenSSH** running on a **musl**-based Linux distribution (e.g., **Alpine Linux**, **OpenWrt**, **Buildroot**, **Yocto**). * **PAM** authentication is disabled (which is the default for **Alpine Linux**'s `openssh-server` package). * **SSH** password authentication is enabled. * At least one account has an asterisk (`*`) as its password hash in `/etc/shadow`. * Another account possesses a valid password hash (this condition is likely to be met in most systems). **Kultekin** specifically highlighted that official **Alpine Linux** AWS and Azure cloud images are vulnerable by default due to an 'alpine' account with passwordless `doas` privileges, potentially allowing attackers to gain root access. Systems using **glibc** (such as **Debian**, **Ubuntu**, **Fedora**) or those with **PAM** authentication enabled are not susceptible to this attack vector. ### Discovery and Remediation **Kultekin**'s discovery leveraged AI agents, which conducted approximately 17,600 authentication tests across various **OpenSSH** configurations, malformed password hashes, and oversized passwords. The vulnerability has been addressed in **OpenSSH 10.6p2**. **Alpine Linux** administrators are strongly advised to update their **OpenSSH** packages immediately using `apk upgrade openssh`. For those unable to apply the update immediately, a temporary mitigation involves disabling **SSH** password authentication by setting `PasswordAuthentication no` in the **SSH** server configuration and restarting the **SSH** service. Administrators should also review **SSH** authentication logs for any suspicious password-based logins on accounts that should not permit them. On **Alpine Linux**, successful **SSH** password logins can be identified with the command: ```bash grep "Accepted password" /var/log/messages bash grep '^alpine:' /etc/shadow ``` An asterisk (`*`) in the password field coupled with a successful password login in the logs would indicate potential exploitation.