What to Do About the OpenSSH SSHole Flaw on Your Server

Attackers started trying the OpenSSH SSHole flaw less than nine hours after its November 5 disclosure, and CISA added it to its Known Exploited Vulnerabilities catalog on November 9. If you run Alpine Linux or another musl-based system with an unpatched OpenSSH server that checks passwords without PAM, update OpenSSH, restart sshd, and turn off password logins. Standard Ubuntu, Debian, Fedora, and RHEL installs are outside the affected group.

What’s at stake? If your server meets the conditions below, someone who can reach port 22 can sign in to an account that was meant to reject passwords. On some Alpine cloud images, that account can give them root access. Here are the facts to check first.

Item	Details
Name and CVE	SSHole, also written *sshole, tracked as CVE-2026-123158
Severity	CVSS 8.1 High. OpenSSH describes its fix as critical.
Disclosed and fixed	November 5, 2026, with the upstream fix in OpenSSH 10.6p2.
Who is exposed	Unpatched OpenSSH on musl-based Linux with PAM off, password logins on, and the account conditions below
Outside the affected group	Stock Ubuntu, Debian, Fedora, and RHEL, plus PAM-enabled setups, Dropbear, macOS, and OpenBSD
Exploited	Attempts began within hours. Previdian confirmed root access on a honeypot. CISA listed the flaw on November 9.
Alpine fix	Upgrade the openssh package, then restart sshd
Quick workaround	Set PasswordAuthentication no and restart sshd.

What the OpenSSH SSHole Bug Actually Does

A key-only account on your server can have an asterisk in its password field instead of a password hash. When musl fails to hash an unusually long password, it can return that same asterisk as an error. An unpatched sshd can read the two matching values as a successful password check. So how did an error end up looking like a valid login?

The behavior dates back to 2012, when musl began returning an asterisk for that failure. In 2016, OpenSSH changed how it checks accounts without passwords to make valid usernames harder to guess. Around 2022, Alpine started shipping root with an asterisk in its password field so key logins could still work.

Özgün Kültekin of Wakefield reported the flaw on November 4. OpenSSH released 10.6p2 the next day. The project traced the cause outside sshd and changed the server so it could avoid the false match.

Is Your Server Exposed to SSHole

Seeing OpenSSH on your server tells you very little on its own. For SSHole to work against an unpatched server, all four of these conditions have to be true.

• musl without PAM. Your Linux system uses musl, and sshd checks passwords without PAM. That includes Alpine’s standard openssh-server package or its PAM build with UsePAM no.
• Password logins enabled. Your server allows password authentication. OpenSSH defaults to PasswordAuthentication yes unless your configuration changes it.
• An account with an asterisk. Check for a login-eligible account with * in its password field. Examples include key-only users and the alpine user on tiny-cloud images. Directory users served through musl-nscd can qualify too.
• A real password hash elsewhere. At least one other local account must have a SHA-256 hash starting with $5$ or a SHA-512 hash starting with $6$.

Systems You Can Stop Worrying About

Debian’s tracker labels some package versions vulnerable based on their version numbers. A standard Debian install uses glibc and PAM, which puts it outside the exploitable setup. The same check lets you rule out these systems and accounts.

• Stock Ubuntu, Debian, Raspberry Pi OS, Fedora, RHEL, Rocky Linux, and AlmaLinux.
• macOS, OpenBSD, and OpenWrt devices using the default Dropbear server.
• OpenSSH servers that check passwords through PAM or enforce PasswordAuthentication no, including cloud images where cloud-init has applied that directive.
• Individual accounts locked with ! in the password field.

Where Home Labs and Small Sites Get Caught

• Alpine VPS or VM. Start here if you run home lab services exposed to the internet and your SSH port is reachable too.
• Alpine on AWS or Azure. Check instances launched from tiny-cloud images in the 3.18.11 to 3.24.3 range. Setting a console password can add the hash that makes a previously safe instance exploitable.
• Proxmox LXC or Docker. Check inside Alpine containers that run sshd, including custom builds. If you use linuxserver/openssh-server, check whether you changed PASSWORD_ACCESS from its default of false.
• Routers and embedded devices. Check musl-based OpenWrt, Buildroot, and Yocto devices that run OpenSSH. On OpenWrt, look for devices where you replaced Dropbear.

What PermitRootLogin Does and Doesn’t Protect

The default PermitRootLogin prohibit-password blocks direct password logins as root. On affected tiny-cloud images, though, an attacker who gets in as alpine can use passwordless doas to become root. Check the accounts that can become root as well as the root login rule.

How to Check Your OpenSSH Version and Setup

Start with the machine or container that actually runs sshd. These checks take you from the operating system to the package revision and the accounts the flaw could affect.

1. Confirm the OS and C library. On Alpine, read the release file, then check what sshd links against and look for musl, glibc, and libpam.

cat /etc/alpine-release
ldd /usr/sbin/sshd

2. Check the OpenSSH version. The first command reports the client version and the second reports the server version where supported, but both show upstream numbers.

ssh -V
sshd -V

3. Find the Alpine package revision. Compare the full revision with the table below, since Alpine 3.24 has the fix in 10.3_p1-r2 even though OpenSSH still reports 10.3.

apk info -v | grep '^openssh'

4. Read the SSH configuration. Run this as root to see the global values, then check Match blocks and files under /etc/ssh/sshd_config.d/ for rules that allow passwords for specific connections.

sshd -T | grep -Ei '^(usepam|passwordauthentication|permitrootlogin) '

5. Check local account types. Run both commands as root to list usernames with an asterisk first and usernames with a $5$ or $6$ hash second, without printing any hashes.

awk -F '\072' '$2 == "*" {print $1}' /etc/shadow
awk -F '\072' '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadow

6. Check the package on other distributions. Use the first command on Debian or Ubuntu and the second on RHEL or Fedora to see which server package you have installed.

dpkg -l openssh-server
rpm -q openssh-server

Stick to local checks. Previdian warns that unverified SSHole scripts on GitHub could contain malware.

Fixed Alpine Package Versions by Branch

Alpine applied the patch to older OpenSSH versions, so the full package revision tells you whether your branch has the fix. Find your branch below and compare your installed revision with the first fixed package in the Alpine Linux security advisory.

Alpine branch	First fixed openssh package	Notes
edge	10.6_p2-r0	Uses the upstream fix
3.24	10.3_p1-r2	Included in 3.24.4
3.23	10.2_p1-r1	Included in 3.23.8
3.22	10.0_p1-r11	Included in 3.22.8
3.21	9.9_p2-r1	Included in 3.21.10. Support ended November 1, 2026.
3.20	9.7_p1-r6	Out of support. Package fix only.
3.19	9.6_p1-r3	Out of support. Package fix only.
3.18	9.3_p2-r4	Out of support. Package fix only.
3.17	9.1_p1-r7	Out of support. Package fix only.
3.16	9.0_p1-r6	Out of support. Package fix only.

If you run Alpine 3.15 or earlier, upgrade Alpine or disable password logins, since those branches received no fixed package. If you build OpenSSH from upstream, use 10.6p2 or later.

How to Patch OpenSSH SSHole on Alpine, Docker and Other Systems

The fixed package is only part of the job. On Alpine, the running SSH server keeps using the old code until you restart it. In Docker, you need to recreate the container from a fixed image. Start with the steps for the system that actually runs sshd.

Alpine Servers and VMs

1. Update the packages. Run the upgrade as root on your Alpine server or VM.

apk upgrade -U -a

2. Restart the SSH server. Once the upgrade succeeds, restart sshd so it loads the patched code.

rc-service sshd restart

3. Verify the result. Compare your installed package revision with the table above and confirm that SSH is using the password authentication policy you expect.

apk info -v | grep '^openssh'
sshd -T | grep -i '^passwordauthentication '

Docker Containers Built on Alpine

1. Find the containers running SSH. List your running containers, then replace CONTAINER with the name of one you want to check. Look for sshd in the process list and the openssh-server package in the package output. Containers without a running SSH server are outside the scope of SSHole.

docker ps
docker exec CONTAINER ps
docker exec CONTAINER apk info -v | grep '^openssh-server'

2. Get a fixed image. Pull the updated image if someone else maintains it. If you build it yourself, rebuild on Alpine 3.24.4 or later and include the updated OpenSSH package.
3. Recreate the container. Restarting the old container keeps it on the old image. For a service that pulls its image, run both Compose commands and replace SSH_SERVICE with your service name. If you’ve already rebuilt the image locally, run the second command to recreate the service.

docker compose pull SSH_SERVICE &&
  docker compose up -d --force-recreate SSH_SERVICE

Cloud Images, Routers and Other musl Devices

• Running Alpine cloud instances. Patch your existing AWS or Azure instances directly. A fixed image in the catalog only helps instances launched from that image.
• Routers and embedded devices. If your device runs OpenSSH on musl, install the fixed package or firmware. On OpenWrt, you can also switch back to Dropbear.
• Unsupported Alpine releases. Move to a supported branch. If you’re on Alpine 3.15 or earlier, turn off password logins while you arrange the upgrade.

Temporary Fixes If You Can’t Update Today

Turning off SSH password authentication blocks the bypass. If you’re making the change over SSH, keep your current session open until you’ve tested a fresh key login. Follow these steps on Alpine.

1. Test your key. Open a second connection and confirm you can sign in with your SSH key.
2. Turn off password authentication. On Alpine 3.19 or later with the default configuration, put PasswordAuthentication no in /etc/ssh/sshd_config.d/00-no-passwords.conf. On older releases, edit /etc/ssh/sshd_config directly. Check the main file and included files for PasswordAuthentication yes, including inside Match blocks, and change those directives to no.
3. Validate and restart. Run this as root so sshd restarts only if the configuration check passes.

sshd -t && rc-service sshd restart

4. Verify before you disconnect. Look for passwordauthentication no, then open a fresh key-based session before closing the one you kept open.

sshd -T | grep -i '^passwordauthentication '

• Restrict port 22. Limit it to your IP through a firewall or cloud security group, or stop exposing it publicly by putting SSH behind a VPN.
• Keep direct root access limited. Leave PermitRootLogin at prohibit-password or set it to no.
• Check PAM and account locks. Alpine’s openssh-server-pam with UsePAM yes is outside the affected configuration. On builds without PAM, locking an account with ! also blocks its key logins.
• Turn off unused SSH. If you never connect to the machine over SSH, disable the service.

Signs Someone Already Got In

If your server was exposed, look back through its SSH logs even after you patch. Start with /var/log/messages on Alpine or your central logs, then check for changes made after a suspicious login.

• Unexpected password login. Look for Accepted password for entries naming root, alpine, or a key-only user that should reject passwords. Check for a failure followed by success in the same session.
• Changes to access. Look for unfamiliar keys in authorized_keys, especially for alpine or root, along with new users or doas activity you can’t account for.
• Changes to the system. Look for new scripts in /etc/init.d or edits to /etc/hosts, /etc/resolv.conf, or /etc/apk/repositories.
• Unexpected processes. Check for a second sshd listening on a port such as 2222 or an unexplained jump in CPU usage.

Previdian observed attackers inspecting an Alpine honeypot and confirmed that they gained root access. GreyNoise observed attackers probe cloud instance metadata, try to retrieve password hashes and SSH keys, add their own SSH keys, and run a Python agent for remote control. WatchTowr identified botnets and crypto miners among the early users. SANS honeypots recorded a peak of 713 unusually long password attempts on November 6.

If you find a suspicious login you can’t rule out, treat the machine as compromised.

1. Rebuild the machine from a clean image.
2. Rotate the SSH keys, API tokens, cloud credentials, and deployment credentials it held.
3. Check the other machines it could reach.

Your Next Steps This Week

If you run a standard Ubuntu or Debian server, you can set aside this particular alert. If Alpine runs your SSH server, check its package revision today. Subscribe to your distribution’s security announcements, and use a recent self-hosted server vulnerability as a reminder to follow updates for the other software you run. Here’s what to put on your list.

• Check what runs SSH. Include your VMs and containers.
• Patch and restart. Restart sshd on Alpine hosts and recreate affected containers from a fixed image.
• Tighten account access. Keep SSH key-only, restrict who can reach it, and consider adding a second factor to your logins on services that support it.
• Review your logs. Check whether any key-only account accepted a password while your server was exposed.

FAQs