sshole: OpenSSH on Alpine Linux Accepts Any Password Over 256 Bytes, Patch 10.6p2

If you run sshd on Alpine Linux, OpenWrt or any other musl-based system with password authentication on, any string longer than 256 bytes can be a valid password for an account that has no password set. The bug, nicknamed sshole and written up at sshhole.com, sat in OpenSSH Portable's interaction with musl for years. OpenSSH Portable 10.6p2 fixes it, and Alpine has shipped updated packages.

This post covers the mechanism, who is exposed, and the exact commands to close it. It matters beyond servers: Alpine is the base of a huge share of Docker images, including images used as agent sandboxes and dev containers.

TL;DR

How the 256-byte bypass works

Two old behaviours meet in one comparison:

1. musl crypt() returns "*" on failure instead of NULL (changed in 2012). Its SHA-512 crypt also rejects passwords over 256 bytes, so a long input is a failure.
2. Locked or key-only accounts store * in the /etc/shadow password field. Alpine's root account uses * since Alpine 3.16.
3. sshd hashes attempts for locked accounts anyway, using a borrowed salt, to stop user enumeration by timing (the 2016 change related to CVE-2016-6210).

Put together: you try to log in as root with a 300-byte password. sshd finds no usable hash, hashes your input with another account's salt, crypt() fails and returns "*", and sshd compares "*" to the stored "*". They match. You are in.

No cryptography is broken. A failure value and a "no password" marker happen to be the same string.

Who should patch first

• Alpine hosts and containers running openssh-server, which is not PAM-linked by default.
• OpenWrt routers and appliances with SSH exposed to a LAN or the internet.
• Buildroot and Yocto images and any embedded device using musl sshd.
• Docker images that run sshd for debugging, CI runners or agent sandboxes.

Accounts at risk are the ones with * as the password field: key-only users, LDAP-backed accounts, and Alpine's root. Accounts with a real hash are not the target of this path.

What to do now

# Alpine
apk upgrade -U -a
rc-service sshd restart        # or: service sshd restart

# Confirm the version
sshd -V 2>&1 | head -1

# No patch available yet: turn password auth off
echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config
rc-service sshd restart

Then check for compromise. Look for successful password logins to accounts that should have none:

grep -E 'Accepted password for (root|[a-z_-]+)' /var/log/messages /var/log/auth.log 2>/dev/null
last -a | head -30

If anything looks wrong, treat the host as compromised: rotate secrets stored on it, review authorized_keys, and rebuild from a clean image rather than cleaning in place. Moving to SSH keys and keeping password authentication off removes this whole class of bug.

What is confirmed and what is not

Everything above on the mechanism, the affected configuration and the fix version comes from the sshhole.com write-up, which says OpenSSH 10.6p2 fixes it (an OpenSSH commit corrected pick_salt() handling on October 30, 2026). I did not reproduce the bypass myself. The write-up lists no CVE for sshole itself, and reports of exploitation in the wild had not been confirmed at the time of writing. Social posts describing "root on Alpine with any long string" are accurate only for the configuration above, not for every Linux box.

Why this matters for AI coding agents

Agents increasingly run inside containers, and Alpine is a common base. An agent sandbox with sshd for remote access, or a dev container shared on a network, is exactly the kind of host where a forgotten root * entry turns a bug into shell access, and from there to every token the agent can reach. Related incidents show how fast host access becomes credential theft: a compromised Claude Code VS Code extension with an SSH backdoor, a LiteLLM release that stole AI credentials, and a Linux root exploit pipeline. Patching sshd is the fix here; watching what runs on those hosts is the backstop.

How Beam handles this

Beam is local-first monitoring for AI coding agents, not a network SSH scanner, so it does not patch or detect sshole. What it does cover is the next step: if an agent session or a host it runs on is taken over, Beam flags credential exposure, destructive commands and privilege escalation in the agent's own tool calls, with redaction before anything is stored. Enforcement is hook-based (Claude Code and Codex PreToolUse), not a kernel sandbox. See how Beam watches agent activity.

Related reading

• November 2026 attacks timeline
• Compromised Claude Code VS Code extension with an SSH backdoor
• Tailworm: Tailscale SSH flaws and root access, claimed vs verified
• Linux root exploits and what to patch
• LiteLLM 1.107.0 compromise

Details reflect the sshhole.com write-up and public discussion as of November 5, 2026. Patch availability and advisories may change; check your distribution's security tracker before acting.