SSH exposed to the internet

An SSH daemon on a public IP starts receiving automated authentication attempts within minutes of the address becoming routable. No one has to find you: the whole address space is scanned continuously and indexed, and a new listener is picked up on the next pass.

This page is about what that traffic can and can’t do, so you can tell the difference between noise and a problem.

What the noise is

Nearly all of it is one thing: credential guessing against password authentication, from botnets working through common usernames (root, admin, ubuntu, test, oracle, git) and common passwords. It is untargeted and indiscriminate.

That is why the exposure collapses the moment there is no password to guess. Against a key-only daemon, the same traffic produces the same rejection every time, forever. The volume is unchanged; the risk is not.

What actually gets hosts compromised

In rough order of how often they matter:

1. Password authentication left on, with an account whose password is guessable. This is the overwhelming majority.
2. A reused or leaked key with no passphrase, copied from a compromised workstation or an over-shared backup.
3. An account nobody remembered — a service or vendor account with a shell and a default credential, which the allow-list would have excluded.
4. Agent forwarding into a compromised host, letting it authenticate onward as you.

Notice what isn’t on that list: exotic cryptographic attacks against the transport. Modern OpenSSH’s defaults are not what fails.

The shortest path from exposed to closed

In this order — each step reduces what the next one has to handle:

1. Require key-only authentication — removes the thing being guessed. This alone closes most of it.
2. Disable root login — removes the account that needs no username guess.
3. Restrict which users can log in — excludes the accounts you forgot about, including ones that don’t exist yet.
4. Firewall the port — if you have a fixed administrative address or a bastion, the daemon stops being reachable at all. This is the strongest of the four.

Steps 1–3 take a few minutes and need no infrastructure. Step 4 needs a stable source address, which is why it is listed last despite being the most effective.

Verify it worked

Find out what is actually exposed, from outside the host:

# from another machine
nc -zv -w 5 your.host 22

Then confirm what the daemon accepts, rather than what you believe it accepts:

sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

The exposure is closed when the first two report no. Anything else means passwords are still guessable, whatever the rest of the config says.

To see the traffic itself:

sudo journalctl -u ssh --since "24 hours ago" | grep -ci 'Failed password'

A large number here is expected and is not, by itself, an incident. A non-zero count of Accepted password on a host you believe is key-only is.

Before you apply this

Nothing on this page changes a running system, but one warning about reading it:

Do not respond to scan volume by only adding Fail2Ban or changing the port. Both make the logs quieter, which feels like progress and can leave the actual exposure — password authentication — untouched. Quiet logs on a host that still accepts passwords is the worst of both worlds: the same risk, with less evidence.

Close the authentication path first. Then make the logs quiet.

Related

• Hardening SSH — the full checklist.
• Set up Fail2Ban for SSH — for the noise, once the risk is handled.