Attackers have begun probing a password bypass in certain OpenSSH servers after SANS Internet Storm Center researchers saw clear exploit attempts. The flaw affects some password-disabled Linux accounts when an unusually long password is sent, and the evidence so far points to active exploitation attempts rather than confirmed compromise.
Live probes against password-disabled accounts
SANS researcher Johannes Ullrich said the first clear attempts appeared on November 5, when the passwords consisted of repeated A characters. His Cowrie SSH honeypots saw 232 long-password requests that day and 713 on November 6. Those counts reflect suspicious requests, not confirmed compromises or distinct attackers.
Long-password activity showed up earlier, on November 1, but Ullrich said those early entries looked like broken brute-force scripts rather than deliberate SSHole exploitation. Some scripts placed download commands into the password field. Cowrie keeps only the first 255 password characters, which limits how fully researchers can inspect attempts that use longer inputs.
What the SSHole flaw accepts
Özgün Kültekin disclosed SSHole, which affects OpenSSH running with musl libc when password checks happen without PAM, the Linux login framework. The attack also needs password authentication to be enabled, a target account whose stored password field is *, and another local account with a valid SHA-crypt password hash.
Kültekin’s technical disclosure says the failure happens when a password longer than 256 bytes causes musl’s crypt() function to return * as an error signal. OpenSSH can compare that value with the target account’s stored * and accept the login. The documented attack range runs from 257 to 1,024 bytes, and accounts with valid password hashes are not bypassed in this way.
Addresses and outcome remain uncertain
The leading scanner addresses included 213.86.169.133, 152.233.50.185, and 92.255.57.7, with 48, 44, and 43 recorded attempts, respectively. Ullrich suspected some honeypot logins succeeded, but his report did not confirm successful sessions. The evidence supports exploitation attempts, while the full outcome remains unresolved.
Patch status and defensive checks
OpenSSH 10.6p2 fixes the issue, and Alpine has released patched packages. Administrators should install distribution updates and restart sshd. Where patching must wait, setting PasswordAuthentication no blocks this attack path, and StepSecurity’s testing confirmed protection when password checks use PAM. Package revisions still matter because backported fixes may keep older OpenSSH version banners.
Review successful password logins to key-only accounts, especially failures followed by acceptance within one session. Earlier SSH honeypot research shows why post-login monitoring matters. The cited evidence does not establish an SSH option that leaks passwords or API keys to GitHub, and that claim is separate from this authentication bypass.
Licensed under CC BY-ND 4.0 International