# *sshole: OpenSSH vulnerability allows logins without a valid password on Alpine Linux

> URL: https://maxanoo.com/sshole-openssh-vulnerability-alpine-linux/ · Autor: Sebastian · Veröffentlicht: 2026-11-05 · Aktualisiert: 2026-11-05

On Linux systems with musl and without PAM, OpenSSH accepts any overlong password for certain accounts. Who is affected, how to check and what to do now.

OpenSSH 10.6p2 was released on 5 November 2026. It contains a workaround for a vulnerability that its discoverer Özgün Kültekin calls **\*sshole**. On certain Linux systems an attacker can log in via SSH to accounts that have no password at all. Any overlong password will do.

The vulnerability only applies when several conditions come together. Debian, Ubuntu and Fedora are not affected in their standard configuration. If you run Alpine Linux or another musl-based system, check today. The reports I have read did not yet list a CVE number, and they do not report any attacks so far.

## What happens technically?

The cause lies in the interaction between OpenSSH and the C library musl. For passwords longer than 256 bytes, musl's `crypt()` function fails and returns `*` as its error marker. In `/etc/shadow`, the same character means that the account has no password. OpenSSH compares the two values, they match, and the login counts as successful. Alpine names passwords of 257 to 1024 bytes as the trigger.

## Who is affected

All of these conditions have to apply at the same time:

1. OpenSSH runs on a Linux system with **musl**, such as Alpine, Buildroot or Yocto, or in an image based on one of them.
2. OpenSSH runs **without PAM**. This is the case for Alpine's standard `openssh-server` package.
3. **Password logins** are enabled. That is the default.
4. The target account has `*` in its password field, which is typical for users who only log in with a key or through LDAP.
5. At least one other account has a real password.

According to Kültekin, this applies to the official Alpine images for AWS and Azure. Their default user `alpine` can run commands as root via `doas` without a password, so a login to this account means full control of the server.

## Who is not affected

- Systems with glibc, meaning Debian, Ubuntu and Fedora in their standard configuration
- OpenSSH with PAM enabled, which on Alpine means `openssh-server-pam` with `UsePAM yes`
- Dropbear, the default SSH server on OpenWrt
- Accounts locked with `!` instead of `*`
- Containers without a running SSH service, which is most Alpine containers

## How bad is it?

If everything applies, it is very serious: an attacker only needs a reachable SSH port and a matching account name, and the details are public. For many systems, though, the conditions reduce the risk considerably. Direct root login with a password stays blocked as long as `PermitRootLogin` is at its default of `prohibit-password`. Most at risk are Alpine servers and embedded devices running OpenSSH with an SSH port reachable from the internet.

## How to check your server

Run these commands on the server itself, as root. They do not change anything.

1. **musl?** `ldd /usr/sbin/sshd | grep musl`. Without a match, the system is not affected as far as is known today.
2. **Password login and PAM?** `sshd -T | grep -Ei 'usepam|passwordauthentication'`. With `passwordauthentication no` or `usepam yes` the vulnerability does not apply.
3. **Accounts with an asterisk?** `awk -F: '$2=="*" {print $1}' /etc/shadow`. Check in `/etc/passwd` whether the listed accounts have a login shell.

## What to do now

1. **Install the update.** On Alpine: `apk upgrade -U -a`. The fix is included in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4, and patched packages exist for older branches. An older OpenSSH version number therefore does not automatically mean your system is open. For Buildroot, Yocto and devices with their own firmware you need OpenSSH 10.6p2 or a patch from the vendor.
2. **Restart the service.** `rc-service sshd restart`. Without a restart the old service keeps running.
3. **If the update has to wait:** switch off password logins. Add `PasswordAuthentication no` to `/etc/ssh/sshd_config.d/00-no-passwords.conf`, check it with `sshd -t` and restart the service. First test in a second session that your key login works, and keep the existing session open. Otherwise you can lock yourself out.

## Look for traces

The flaw existed for many years, so an update alone does not tell you whether someone has already been in. Search the SSH logs for successful password logins, on Alpine for example with `grep 'Accepted password' /var/log/messages`. The path depends on the system. A match on an account with `*` is a red flag, because that account has no password. Also check `authorized_keys`, new user accounts and cron jobs. If you cannot rule out unauthorised access, treat the server as compromised: set it up again and replace keys and credentials.

## Not sure whether this affects you?

That is normal. If you run a website or a shop, you do not have to know which Linux runs underneath it. These three cases will help you place yourself:

- **Regular web hosting or a managed server:** your provider looks after the operating system. If in doubt, ask them briefly.
- **Your own server, looked after by an agency or service provider:** ask exactly this: "Are we running OpenSSH on Alpine Linux or another musl-based system, and is the fix for \*sshole installed?"
- **Your own server that nobody looks after, or you do not know the answer:** then someone should check it for you.

I am happy to help with that. I check whether your servers are affected, install the update, switch off password logins and search the logs for traces. You do not need any technical knowledge for this. Just [write to me](/contact/) and tell me where your website is hosted or who looks after it. Please do not send passwords by email; we will sort out access together afterwards.

Sources: [Özgün Kültekin: \*sshole](https://sshhole.com) · [Cyber Security News: OpenSSH and Alpine updates](https://cybersecuritynews.com/openssh-flaw-bypass-password-authentication/). As of 5 November 2026.