An Oversized Password Can Log You Into Locked Accounts on Alpine-Based OpenSSH Servers. Which of Your Hosts Still Accept SSH Passwords?

A newly disclosed flaw nicknamed "*sshole" lets an attacker log into Linux accounts that are meant to block password logins, by submitting a password longer than 256 bytes to an OpenSSH server running on the musl C library. According to BleepingComputer, published 5 November 2026, researcher Ozgun Kultekin says the behaviour has existed since 2016 and is fixed in OpenSSH 10.6p2. The report does not assign a CVE or CVSS score, and it does not say the flaw has been exploited in the wild.

How it works

Administrators commonly disable password login for an account by putting * in its password-hash field in /etc/shadow. Per the report, the 2016 fix for CVE-2016-6210 made OpenSSH hash a submitted password even for accounts with no usable hash, so response timing cannot reveal which usernames exist. On musl, crypt() also returns * when hashing fails, including when the password exceeds its 256-byte limit. An oversized password therefore produces *, which matches the stored * and grants a login. Accounts with a valid password hash are not bypassed.

What has to be true

Kultekin lists these conditions, all of which must hold:

• OpenSSH on a musl-based system such as Alpine Linux, OpenWrt, Buildroot or Yocto
• PAM authentication disabled (the default in Alpine's openssh-server package)
• SSH password authentication enabled
• At least one account whose hash is *
• Another account with a valid password hash

Glibc systems (Debian, Ubuntu, Fedora) and PAM-based setups are not affected. The report adds that Alpine's official AWS and Azure cloud images ship a default alpine account with passwordless doas, which the researcher warns could turn a login into root access.

Kultekin says he found the issue with AI agents that ran about 17,600 authentication tests across configurations, malformed hashes and oversized passwords. The article does not name affected OpenSSH version ranges.

What to check

1. Upgrade to OpenSSH 10.6p2. On Alpine: apk upgrade openssh.
2. If you cannot patch yet, set PasswordAuthentication no in the SSH server configuration and restart the service.
3. Check logs for signs of use. On Alpine, grep "Accepted password" /var/log/messages, then grep '^alpine:' /etc/shadow. If an account's hash is * but the log shows a successful password login, treat it as possible exploitation.
4. Find embedded and container images. musl is common in routers, appliances and minimal containers, where nobody thinks of the OpenSSH build as something to patch.
5. Prefer keys over passwords on anything reachable from the internet.

This is a different kind of exposure from the one in our GitLab and Alpine analysis: that story was about a patched version still being vulnerable; this one is about a long-standing default interacting with a library edge case.

How Obiguard Scout fits

The conditions above start with something visible from outside: an SSH service that offers password authentication. Obiguard Scout is our external attack surface product. It maps the hosts and services your organisation exposes to the internet, so port 22 listeners that accept passwords, on cloud images, gateways or forgotten test machines, appear in an inventory you can sort by what is reachable. That gives you the list to patch or lock down first. Scout sees only what is visible from outside: it cannot confirm whether a host is musl-based, whether PAM is on, or whether an account has a * hash. Those checks still need access to the host. You can run a free Scout check on a domain you own to see which services are already published under it.

Sources

• BleepingComputer: OpenSSH flaw lets attackers log into password-disabled Linux accounts
• Researcher disclosure page (sshhole.com)