I Sent a 300-Byte Password at a Key-Only Account. It Let Me In.

Here’s the part that should bother you. The account I logged into had no password. None. It was a key-only account, the kind you set up precisely so that nobody can guess their way in. And a string of the right length walked straight past the lock as if the door had been left open the whole time.

That’s the shape of CVE-2026-123158, the flaw the community has already christened *sshole. OpenSSH shipped an emergency fix for it, rated it critical, and if you run Alpine Linux SSH servers you want to be patched before you finish your coffee. Let me build this up from nothing, because the mechanism is more interesting, and more worrying, than “there’s a bug, go patch.”

Start with what SSH authentication actually promises

When you connect to a server over SSH, the server has to answer one question: are you allowed in? It does that through authentication methods. The two you care about here are password authentication and public-key authentication.

Password auth is the obvious one. You type a secret, the server checks it against the stored hash, and if they match, you’re in. Public-key auth is the grown-up version: you prove you hold a private key that matches a public key the server already trusts, and no secret ever crosses the wire. Most hardened fleets run key-only, password auth disabled, or accounts with no password hash set at all.

Think of it like a building with two entrances. One has a keypad (the password). The other has a badge reader (the key). A “key-only account” is supposed to be a door where the keypad has been removed and bricked over. There is no code to guess because there is no keypad. That’s the entire point of the design, you can’t brute-force a keypad that doesn’t exist.

Except on an affected Alpine build, the keypad was never really gone. It was hidden behind the wall, still wired in, and if you pushed the right number of buttons it would buzz you through regardless of what the account was supposed to allow.

Why the length of the password is the whole bug

Normally when you offer a password that doesn’t match, the server rejects it. Simple. The defect here isn’t about matching the right password, it’s about what the code does when the password is a specific size.

On affected systems, a password between 257 and 1,024 bytes doesn’t get checked the way a normal password does. It trips a path in the authentication handling where the “does this match?” logic effectively returns success, or never runs at all, and the connection is treated as authenticated. The value of the string doesn’t matter. The length does.

Here’s the analogy I keep coming back to. Imagine a bouncer who checks IDs by comparing them to a list. Normal-sized ID, he reads it, checks the list, waves you off if you’re not on it. But hand him an ID that’s too big to fit in his hand and his brain short-circuits, he shrugs and lets you through rather than deal with it. You didn’t forge anything. You just handed him something he wasn’t built to hold.

That’s why this is rated critical instead of annoying. It isn’t a brute-force shortcut. It isn’t a timing leak you’d need a million samples to exploit. It’s a one-shot bypass: valid account name plus one oversized password, and the authentication decision comes back wrong.

The “no password” protection is exactly what fails

This is the detail that flips people’s mental model, so sit with it. Teams assume a key-only account is safer than a password account because there’s no password to steal or guess. Under this bug, that assumption inverts.

The vulnerable code path doesn’t care whether the account has a usable password set. The length-triggered shortcut bypasses the check that would normally say “this account has no password, reject.” So the accounts you were most confident about, service accounts, deploy users, the root you locked down to keys months ago, are exactly the ones an attacker can reach, as long as they can name them and reach port 22.

The attack requirements are depressingly low: network access to the SSH service, a valid account name (and usernames are rarely secret, root, deploy, ansible, git), and a crafted long password. No key. No existing credential. No foothold.

Who’s actually exposed

Confirmed: Alpine Linux running the standard openssh-server package. Alpine is widely used as a container base image, so “I don’t run Alpine servers” doesn’t let you off the hook if your images ship an SSH daemon. Check your containers, not just your VMs.

Other distributions may be affected depending on how they build and patch OpenSSH; treat that as open until your vendor’s advisory says otherwise. Don’t assume you’re clear, and don’t assume every OpenSSH on earth is doomed either. Verify.

Audit your exposure right now

This is read-only. It reports what you’re running and whether SSH is listening; it changes nothing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/bin/sh
# *sshole (CVE-2026-123158) exposure check, report only, no changes.
​
echo "=== Host: $(hostname) ==="
​
# 1. OpenSSH version reported by the daemon
sshd -V 2>&1 | head -n1 || ssh -V 2>&1 | head -n1
​
# 2. On Alpine: installed openssh-server package version
if [ -f /etc/alpine-release ]; then
  echo "Alpine release: $(cat /etc/alpine-release)"
  apk info -v openssh-server 2>/dev/null || echo "openssh-server not installed via apk"
else
  echo "Not Alpine, confirm status against your distro's advisory."
fi
​
# 3. Is SSH actually listening / network-reachable?
(ss -tlnp 2>/dev/null | grep -E ':22\b') || echo "No listener on :22 (check custom ports)"
​
# 4. Accounts likely to matter: those permitting login
echo "--- Non-nologin shells (candidate accounts) ---"
grep -vE '/(nologin|false)$' /etc/passwd | cut -d: -f1,7

Compare the installed openssh-server version against Alpine’s official security advisory for this CVE. I’m deliberately not printing a “patched version” number here, pin your decision to the advisory for your Alpine branch (edge, v3.x), not to a number you read in an article, because the fixed package differs per branch.

What to do, in order

1. Patch tonight. On Alpine:

1
2
3
4
5
6

# Dry-run first: see what would upgrade
apk upgrade --simulate openssh openssh-server
​
# Then apply and restart the daemon
apk update && apk upgrade openssh openssh-server
rc-service sshd restart   # or: service sshd restart

For containers, rebuild images from a patched Alpine base and redeploy, patching the running container is a band-aid that dies with the next rollout.

2. If you can’t patch this second, blunt the attack surface. Restrict SSH to management networks or a bastion with firewall rules, drop it behind a VPN, or temporarily disable the password authentication method entirely in sshd_config (PasswordAuthentication no plus KbdInteractiveAuthentication no). Note the honest caveat: a bypass this deep may not fully respect config intent, so treat disabling password auth as a reduction, not a cure. Network isolation is the stronger compensating control until the package is updated.

3. Hunt before you relax. Check auth logs for successful logins to key-only accounts that shouldn’t ever use password auth, and for sessions from addresses you don’t recognise. A clean patch doesn’t undo a login that already happened.

Urgency call: immediate. Critical rating, pre-auth, one-shot, no credential required, and it defeats the exact configuration most teams rely on. Emergency releases don’t ship for theoretical problems. Patch the Alpine SSH servers tonight, rebuild the images tomorrow, and read your logs before you decide you got away clean.