Skip to content

SSHHole explained: check the server, not just your SSH keys

Portable OpenSSH 10.6p2, released on November 5, 2026, adds a critical workaround for a password-authentication bypass on certain musl-based Linux configurations without PAM. The OpenSSH team places the root cause outside sshd. Official release notes.

The useful question is not simply “Do I use an SSH key?” It is “Which login methods does this server actually accept for this account?” Here is how to turn the disclosure into a manageable check.

Watch the short explanation

English narration, with on-screen captions. Watch on YouTube.

What went wrong

A password-hashing error can return *, matching an affected account's stored marker. The login check can mistake that error for success. This is an authentication failure, not broken SSH encryption. Alpine.

The OpenSSH patch rejects stored password values too short to be valid hashes and keeps an independent copy of password data. These changes prevent the unsafe comparison in sshd. The important distinction is between comparing two equal strings and establishing that a valid password calculation succeeded.

The conditions matter

Alpine lists these conditions together: PAM unused, password authentication enabled, the target password field exactly *, and another local account with a $5$ or $6$ hash. The * marker differs from a fully locked ! account. Install your branch's fixed package and restart sshd. Affected configurations and fixed packages.

Check effective settings, including relevant Match rules. PermitRootLogin prohibit-password blocks direct root password login, but does not remove privileges held by another account. PasswordAuthentication can be overridden in a matching block. Using keys does not disable a password method that remains allowed. Additional required authentication methods also matter. OpenSSH configuration reference.

A safe administrator's checklist

  1. Identify what you manage. Record each host's owner, operating-system branch and installed package revision. Include image build recipes, so a replacement machine does not quietly restore an old deployment.
  2. Preserve a recovery route. Save a configuration backup and validate changes before restarting. Ubuntu warns that a configuration error can lock you out of a remote server. Ubuntu's safe configuration guidance.
  3. Validate the relevant configuration. The sshd -t mode checks configuration validity. Use -T with -C and representative connection details to inspect applicable Match rules. These checks do not prove that the running service loaded an updated binary. sshd test options.
  4. Close the loop. Record the update and service restart, then verify a fresh authorized login and a routine task. Give unresolved exceptions an owner. Keep password hashes, private keys and credentials out of tickets and screenshots.

This is a review of published evidence, not a test of your server or a claim that it was compromised. The researcher's SSHHole disclosure provides the original report. Use the advisory for your distribution to decide the correct package and service procedure.

לקריאה בעברית

Post a Comment

Previous Post Next Post