{"id":184154,"date":"2026-11-05T23:41:11","date_gmt":"2026-11-05T21:41:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/sshole-uyazvimost-pozvolyayushhaya-podklyuchitsya-po-ssh-bez-parolya-v-sistemah-s-musl"},"modified":"2026-11-05T23:41:15","modified_gmt":"2026-11-05T21:41:15","slug":"sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","title":{"rendered":"SSHole \u2014 a vulnerability that allows password-less SSH connections on systems with Musl","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
The OpenSSH developers have released an emergency update, OpenSSH 10.6p2, which adds protection against a critical vulnerability (CVE not assigned), codenamed 'SSHole', that allows authentication bypass. In systems with the Musl library, the vulnerability enables connecting to a user who does not have a password by entering any password longer than 256 characters. This issue affects Linux distributions using the standard musl library, but not using PAM (Pluggable Authentication Modules), such as OpenWRT, Alpine, Buildroot, and Yocto. The problem is particularly dangerous because password login is often blocked for the root user, allowing anyone to connect remotely with admin rights.<\/p>\n
The flaw leading to the vulnerability lies not in the OpenSSH code itself but is exploited through sshd. Given the seriousness of the issue, a workaround has been proposed in OpenSSH 10.6p2 to block the vulnerability. System owners affected by this problem are advised not to wait for updates, but to immediately disable password authentication using the 'PasswordAuthentication no' option in \/etc\/ssh\/sshd_config or to completely disable SSH. <\/p>\n
The problem does not occur in systems other than Linux, and in Linux environments based on glibc, as well as in systems using PAM for password authentication. A fix is already available in Alpine and OpenWRT.<\/p>\n
The vulnerability is associated with the incorrect interaction between OpenSSH and the crypt() function from musl. To prevent user existence detection through request timing analysis, since 2016, OpenSSH uses a standard password verification procedure when checking passwordless accounts: it calls the 'crypt(pass, salt)' function with the salt of another user that has a valid password hash, and then compares the hash returned by crypt with the value from the password hash field.<\/p>\n
However, in musl the crypt() function for SHA-512 hashes returns the character '*' if the length of the provided password exceeds 256 bytes (this limit was introduced in 2012 to protect against DoS attacks, as passing large values places a significant load on the CPU). The same character is used in the password hash field in '\/etc\/shadow' to indicate accounts for which password authentication is disabled. <\/p>\n
As a result, an attacker with the ability to connect to the SSH server can access any account where the password field in '\/etc\/shadow' is marked with the symbol '*', by sending a string length of between 257 and 1024 bytes. This issue affects many existing Docker images built using Alpine Linux, as well as the official Alpine images for AWS and Azure cloud systems, where the root user has an asterisk '*' instead of a password hash. <\/p>\n