Sshole shows why "set and forget" SSH is a bad habit

When was the last time you actually thought about your SSH daemon? If the honest answer is "when I installed the server," you're in the same boat as most of the internet, and a blunt little website is here to poke at that.

The site is sshhole.com, also known as sshole, and its pitch fits in one line: OpenSSH on musl Linux has been letting people into password-less accounts since 2016. That is the whole of what we have. The page we saw is undated and gives no technical write-up, so we can't explain the exact mechanism, confirm the claim or give you an exploitability score. Treat it as an allegation worth taking seriously, not as established fact.

The scary part isn't the bug, it's the "since 2016"

Every piece of software has bugs. What makes this claim sting is the time span. OpenSSH has one of the best reputations in open source, and its own security page notes old classes of attacks it was never vulnerable to. That reputation is earned. It is also exactly why people stop looking.

Trust is a kind of technical debt. When a component has been boring for years, nobody audits how it's configured, nobody asks what happens on an unusual libc, and nobody puts it on a patch calendar. We think that complacency, more than any single bug, is the real story here. A password-less account is a minor oddity on a lot of machines, the kind of thing people shrug at. Paired with a daemon that lets you in anyway (if the claim holds), it stops being an oddity.

SSH is a single point of failure, and we built it that way

SSH is the front door to servers, containers, routers, build machines and the odd forgotten Raspberry Pi. When it breaks, it doesn't break one app. It breaks the thing that protects everything else. We've normalized that concentration of risk because the tool is good, but good isn't the same as infallible.

This wouldn't be the first time, either. The IsItPatched tracker lists 50 known OpenSSH CVEs, two of them critical (the page is undated, so treat the count as a snapshot). BleepingComputer has reported on OpenSSH security updates fixing a man-in-the-middle flaw and a denial-of-service one, with one of the flaws introduced over a decade ago. Our reading: old code hides old problems, and they surface on their own schedule.

What admins should actually do

First, watch your distribution's security advisories and apply OpenSSH updates as soon as they ship, especially if you run anything on musl. We can't tell you which version fixes the sshole claim, because the documentation we reviewed doesn't say. Read your distro's advisory rather than assuming one command closes the case.

Second, audit for accounts with empty or locked-down passwords. Don't rely on the daemon to refuse them. If the sshole claim holds, that safety net is the thing that failed.

Third, shrink the exposure. Put SSH behind a VPN or an allowlist, don't leave port 22 open to the world, and prefer key-based logins. None of this fixes a bug in the daemon, but it turns "anyone on the internet" into "someone already inside your perimeter," which is a much better problem to have.

Finally, the cultural fix: put OpenSSH on the same patch cadence as your browser. We're not blaming the maintainers. A project this central deserves our gratitude and our attention in equal measure.

Our verdict

Don't panic, and don't shrug. Check your password-less accounts, keep OpenSSH updated, and close SSH to the wider internet where you can. The lesson of sshole isn't that OpenSSH is bad. It's that the tools we trust the most are the ones we've stopped watching.