Understanding the Critical OpenSSH Flaw Called Sshole

A critical OpenSSH vulnerability lets attackers log into certain Linux servers without knowing the password. The flaw, cheekily nicknamed *sshole by its discoverer, affects Alpine Linux and other systems built on the musl C library. Security researcher Özgün Kültekin disclosed it on November 5. OpenSSH rushed out an emergency patch the same day.

The attack is almost absurdly simple. An attacker types any string longer than 256 characters as the password. On affected systems, this gets accepted as valid authentication. *sshole works against accounts configured with an asterisk in the password field, which normally means no password login allowed. Consequently, accounts meant to accept only SSH keys become wide open to anyone who sends a long enough string.

How the Musl C Library and Crypt Function Fail

Understanding why *sshole works requires a quick detour into how passwords get checked. When OpenSSH runs without the Pluggable Authentication Module, it checks passwords itself using the system crypt function. On Alpine Linux, that function comes from musl rather than the more common glibc. When musl crypt receives an input longer than 256 bytes, the hash operation fails. Instead of returning an error, it returns an asterisk.

That asterisk then matches the asterisk stored in the account password field. The system sees a match where none should exist. Essentially, a hashing failure accidentally becomes a successful login. The name *sshole comes from this asterisk behavior, where the * in the password field becomes the hole attackers walk through.

Origins of the Vulnerability and AI Discovery

The vulnerability traces back to a 2016 patch for CVE-2016-6210. That fix addressed a username enumeration issue by making OpenSSH hash passwords even for accounts without usable hashes. The interaction between that patch and musl behavior created this bypass. The *sshole flaw then sat unnoticed for roughly a decade before Kültekin AI agents caught it.

Kültekin specifically noted that official Alpine Linux cloud images for AWS and Azure contain a default alpine account with passwordless privileges. He discovered the *sshole vulnerability using AI agents that ran approximately 17,600 authentication tests. Developers and cloud teams use Alpine Linux extensively in Docker containers and cloud environments, expanding the potential footprint of the issue.

Which Linux Systems Are Affected by the Flaw

As explained by Alpine Linux, you are affected if all of the following are true:

  • You run the Alpine openssh-server package, which is built without PAM, or you run openssh-server-pam with UsePAM no. openssh-server-pam with UsePAM yes is not affected.
  • PasswordAuthentication is yes, the OpenSSH default, unless you changed it.
  • The machine has an account whose password field is *. This includes:
  • root, which ships as root:* in the base image since about Alpine 3.16. OpenSSH default PermitRootLogin prohibit-password protects root, so root is only reachable if PermitRootLogin yes is set. That does not help if another account that can log in is able to become root, for example through doas.
  • Any key-only user created with adduser without a password, or with usermod -p '*'.
  • Users coming from a directory service through musl-nscd, nslcd, winbind, sssd, since they have no shadow entry.
  • The alpine user in the official tiny-cloud images.
  • At least one local account has a $5$ or $6$ password hash.

Affected releases include every Alpine release checked, 3.21 through 3.24 and edge, and older releases that no longer receive regular updates, spanning 3.16 to 3.20.

Conditions Required for Exploitation

Not every Linux system faces this risk, though. The flaw requires three specific conditions simultaneously: the server runs OpenSSH without PAM, password authentication remains enabled, and at least one other account on the machine holds a real password hash. Systems using glibc, or those checking passwords through PAM, remain unaffected entirely.

OpenSSH, which issued an update Thursday, said: We consider the root cause of this bug to be outside sshd, but it is exploitable via sshd and can be avoided there.

The affected surface is not trivial due to the widespread adoption of Alpine Linux in modern containerized infrastructures. Administrators must understand the exact configuration parameters that leave their environments exposed to unauthorized entry attempts.

Emergency Patches and Remediation Steps

OpenSSH released version 10.6p2 to fix the issue. Project developer Damien Miller urged administrators of affected systems to disable password authentication or shut down SSH immediately. The advisory also stated bluntly that administrators should treat any machine with a suspicious login as compromised. They can check for exploitation by searching logs for Accepted password entries.

Security teams need to audit their infrastructure immediately to verify whether password authentication is active on vulnerable Alpine builds. Implementing the official patch or disabling password logins entirely remains the primary defense against active exploitation attempts targeting this flaw.