---
title: "OpenSSH Fixes Critical Long-Password Bypass on Alpine Linux"
date: 2026-11-06
author: "Sofia Ramirez"
featured_image: "https://sqmagazine.co.uk/wp-content/uploads/2026/11/openssh-alpine-linux-flaw-patch.jpg"
categories:
  - name: "Cybersecurity"
    url: "/cybersecurity.md"
tags:
  - name: "News"
    url: "/tag/news.md"
---

# OpenSSH Fixes Critical Long-Password Bypass on Alpine Linux

OpenSSH released version 10.6p2 on November 5, 2026, to block a critical login flaw on some Alpine Linux servers. Any password 257 to 1,024 bytes long opens accounts that have no password.

## Key Facts

- OpenSSH 10.6p2 closes a login bypass on Linux systems that use the musl C library and check passwords without PAM.
- Alpine Linux ships its default openssh-server package in exactly that setup, with password logins switched on.
- Alpine Linux has published fixed packages for every release from 3.16 through 3.24, plus its edge branch.
- Administrators must restart sshd after upgrading, because the package update leaves the old daemon running.

Özgün Kültekin of Wakefield reported the bug and named it “**\*sshole**,” after the asterisk that marks an account with no password set. That asterisk is the whole attack surface. Key-only users, directory-service users and, on Alpine images since about 3.16, root all carry one.

The [OpenSSH release notes](https://www.openssh.org/releasenotes.html) place the root cause “outside sshd” but ship a workaround in the server. Damien Miller of the OpenSSH project urged affected users to switch off password logins or SSH immediately. Glibc distributions such as Debian and Ubuntu, which separately [patched an APT flaw that hands attackers root](https://sqmagazine.co.uk/debian-ubuntu-patch-apt-flaw-attackers-root/), sit outside this one.

> Funny how a password that’s too long can be the one that gets in. On Alpine Linux, musl’s crypt() chokes on 257+ byte passwords and returns \*, which matches passwordless accounts. OpenSSH 10.6p2 fixes it. Upgrade and restart sshd.
> 
> — SQ Magazine (@sqmagazine\_news) [November 6, 2026](https://x.com/sqmagazine_news/status/2118689577502429247?ref_src=twsrc%5Etfw)

## Key-only accounts accept a 257-byte password

[Alpine’s security advisory](https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/) says a server is exposed only when all four of these conditions hold:

- **It runs openssh-server, which Alpine builds without PAM, or openssh-server-pam with UsePAM set to no.**
- **PasswordAuthentication is yes, the OpenSSH default.**
- **An account has a bare \* in its password field.**
- **At least one other local account has a password hash starting with $5$ or $6$.**

The attacker then needs that account’s name and one connection, and the advisory says the attack succeeds on every try.

Root keeps the default **PermitRootLogin prohibit-password guard**, but that guard fails once an exposed account can reach root through doas. Alpine’s official tiny-cloud images from **3.18.11** through **3.24.3** give the alpine user passwordless doas. Those images are safe at first boot and turn exploitable once any $6$ hash appears, for example after an admin sets a console password.

Containers without sshd, cloud-init images and accounts locked with ! are safe. Kültekin also flags OpenWrt, Buildroot and Yocto as musl systems to check, though OpenWrt defaults to Dropbear, which he says is unaffected.

## A 2016 timing fix set up the bypass

The sshd daemon hashes each password attempt with crypt() when PAM is off and compares the result with the stored field. A bare \* is too short to hold a salt, so sshd borrows the salt of another account with a real hash. That borrowing arrived in a July 2016 OpenSSH change for [CVE-2016-6210](https://nvd.nist.gov/vuln/detail/CVE-2016-6210), a username-enumeration bug that attackers triggered by timing responses to long passwords.

**musl’s crypt() refuses passwords over 256 bytes for $5$ and $6$ hashes and returns \* to signal the error. That \* matches the stored \*, and sshd lets the attacker in. The 1,024-byte ceiling is sshd’s own per-password limit.**

Rich Felker, the musl maintainer, called it “**not a bug in musl just an erroneous use by the caller**” in a musl mailing-list advisory. He added that musl will very likely change the underlying behavior in its upcoming release cycle. The idea is not new. In a December 2024 thread on long passwords crashing passwd on Alpine, Felker floated returning an error instead of an unmatchable hash.

The 10.6p2 change makes sshd refuse a match when the stored field is shorter than four characters.

Alpine users should run *apk upgrade -U -a* and then *rc-service sshd restart*. Point releases 3.21.10, 3.22.8, 3.23.8 and 3.24.4 already include the fix. Teams that can’t patch yet should confirm key login works, then set PasswordAuthentication no and restart sshd. Admins should also search /var/log/messages for “**Accepted password for**” lines on accounts such as alpine or root.

**“If you cannot rule out a login, treat the machine as compromised,” the advisory says.**

## The Bottom Line

Two questions stay open. Which CVE will track the bug, given Alpine listed none and some vendors cite an unconfirmed CVE-2026-123158? And how many internet-facing musl hosts still allow password logins?

The fix that matters sits in sshd, since a future musl change can’t reach images already in production. A musl host on OpenSSH older than 10.6p2 that meets all four conditions stays exposed until someone patches and restarts sshd. That includes tiny-cloud instances launched before the new point releases, which Alpine says still need the update or the setting change.