# OpenSSH 10.6p2 fixes Alpine Linux password bypass

URL: https://techaiwire.com/articles/openssh-10-6p2-alpine-linux-password-bypass-sshhole/

_By Claire Whitmore - Nov 5, 2026_

**By the numbers:**

- 257-1,024 - bytes: the password length that gets through
- 17,600 - test logins in the researcher's study; only musl without PAM behaved differently
- 3.16-3.24 - Alpine releases with fixed packages, plus edge

Alpine Linux and the OpenSSH project shipped fixes on November 5, 2026, for a bug that lets an attacker log in to some Alpine servers over SSH without any password. Anyone running Alpine's default SSH server with password logins switched on should update and restart it today.

The flaw "takes one connection, works every time, and needs no retries," the [Alpine security advisory](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) says. Özgün Kültekin of Wakefield reported it. No CVE number had been assigned when Alpine published, and neither project reports any attacks.

## How the password bypass works

The bug sits where OpenSSH meets musl, the small C library Alpine uses instead of glibc. It only appears when sshd, the SSH server, runs without PAM, the shared login system most Linux distributions use.

Without PAM, sshd hashes the password attempt with `crypt()` and compares the result with the account's entry in `/etc/shadow`. Alpine explains that musl's `crypt()` returns `*` as an error for keys over 256 bytes. An account with no password stores that same `*`, so a password of 257 to 1,024 bytes "matches." An account with no usable salt, the random text that makes each hash unique, borrows another account's salt. That is why one local account needs a real `$5$` or `$6$` hash.

The [OpenSSH 10.6p2 release notes](https://www.openssh.org/releasenotes.html#10.6p2) call the update "a critical security workaround" and place the root cause "outside sshd." It follows OpenSSH 10.6, which [shipped in October with post-quantum signatures](/articles/openssh-10-6-post-quantum-signatures-lz77-ai-bug-reports/).

[Kültekin's write-up](https://sshhole.com) names the bug "sshhole" and traces it to two musl commits from August 2012. Of about 17,600 test logins, only musl without PAM behaved differently. It also names OpenWrt, Buildroot and Yocto, which Alpine and OpenSSH do not mention.

## Who is affected, per Alpine's advisory

A machine is exposed only when all four conditions hold:

- sshd comes from `openssh-server`, built without PAM, or from `openssh-server-pam` with `UsePAM no`.
- `PasswordAuthentication` is `yes`, the default.
- An account has `*` as its password field, such as `root`, a key-only user or a directory user from sssd.
- At least one local account has a `$5$` or `$6$` hash.

Containers that do not run sshd are safe, and so are locked accounts marked `!`. The default `PermitRootLogin prohibit-password` blocks password logins for root. It does not protect an account that can become root through `doas`. Alpine's tiny-cloud images from 3.18.11 through 3.24.3 ship such an `alpine` user, with `*` and passwordless `doas`.

## Tested: five Alpine images and their defaults

In a Tech AI Wire test on November 5, on macOS 26.6.2 with Docker 28.4.0, the official `alpine` images installed `openssh-server` from Alpine's live mirrors.

| Branch | Image release (built) | Package installed | Alpine's fixed version | `sshd -V` |
| --- | --- | --- | --- | --- |
| 3.21 | 3.21.9 (Oct 21) | 9.9_p2-r1 | 9.9_p2-r1 | OpenSSH_9.9p2 |
| 3.22 | 3.22.7 (Oct 21) | 10.0_p1-r11 | 10.0_p1-r11 | OpenSSH_10.0p2 |
| 3.23 | 3.23.7 (Oct 21) | 10.2_p1-r1 | 10.2_p1-r1 | OpenSSH_10.2p1 |
| 3.24 | 3.24.3 (Oct 21) | 10.3_p1-r2 | 10.3_p1-r2 | OpenSSH_10.3p1 |
| edge | 3.25.0_alpha20260805 (Aug 6) | 10.6_p2-r0 | 10.6_p2-r0 | OpenSSH_10.6p2 |

Four results matter:

- **New installs get the fix, but the images predate it.** Each reports a release below the fixed 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Stable branches carry the fix inside older OpenSSH versions, so check the package revision, not `sshd -V`.
- **The defaults meet three conditions.** All five run `PasswordAuthentication yes` with `root:*`. On 3.24, the default sshd rejected `UsePAM yes` as an "Unsupported option." The `openssh-server-pam` package's separate `sshd.pam` program still reported `usepam no` on 3.21 and 3.24.
- **A fresh image misses the fourth.** No account has a `$5$` or `$6$` hash until someone sets a password. One `chpasswd` call wrote a `$6$` hash.
- **Making a key-only user work creates a `*` account.** On 3.24, `adduser -D appuser` wrote `!`, and sshd refused its key: "User appuser not allowed because account is locked." BusyBox `passwd -u` left the `!` in place. After `usermod -p '*'`, the key login worked.

## How to check and fix an Alpine server

Three commands show where a server stands. On 3.24, the test printed:

```
$ apk list -I "openssh-server*"
openssh-server-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
openssh-server-common-10.3_p1-r2 aarch64 {openssh} (SSH-OpenSSH) [installed]
$ sshd -T | grep -i passwordauthentication
passwordauthentication yes
$ awk -F: '$2=="*" {print $1}' /etc/shadow
root
```

A package older than the table's fixed version needs the update, and Alpine also fixed the unsupported branches 3.16 to 3.20. Run `apk upgrade -U -a`, then `rc-service sshd restart`. "Upgrading the package alone does not replace the running daemon," the advisory warns.

If updating must wait, Alpine's workaround is a file, `/etc/ssh/sshd_config.d/00-no-passwords.conf`, containing `PasswordAuthentication no`. Confirm key login works first and keep the current session open. In the test, that file turned `sshd -T` from `yes` to `no` on 3.21 and 3.24. Then search `/var/log/messages` for "Accepted password for" a passwordless account.

## What this means for developers

Search Dockerfiles for `openssh-server`. Images that run sshd for CI runners or remote development are the ones in scope. Rebuild them with `docker build --pull --no-cache`, so a layer cached before November 5 cannot bring back the old package.

Make `PasswordAuthentication no` the default for any Alpine machine that only needs keys. Alpine says updating or turning password logins off "closes the hole." The test shows why it matters: the usual way to give a key-only user a working login creates the `*` account this bug needs.

Watch for a CVE number and for word from OpenWrt, Buildroot and Yocto on which of their builds are exposed. The OpenSSH team also says it will ship releases more often for now.

## Sources

- [Security advisory: openssh-server password authentication bypass](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) - Alpine Linux
- [OpenSSH 10.6p2 release notes](https://www.openssh.org/releasenotes.html#10.6p2) - OpenSSH
- [sshhole](https://sshhole.com) - sshhole.com
- [Critical OpenSSH Flaw Could Let Attackers Bypass Password Authentication on Alpine Linux Servers](https://cybersecuritynews.com/openssh-flaw-bypass-password-authentication/) - Cyber Security News
- [Alpine Linux 3.21.10, 3.22.8, 3.23.8 and 3.24.4 Patches Critical SSH Password Bypass](https://www.linuxcompatible.org/story/alpine-linux-32110-3228-3238-and-3244-patches-critical-ssh-password-bypass) - Linux Compatible