Agreed. Another thing you can do to drastically reduce the amount of bots hitting your sshd is to listen on a port that is not 22. In my experience, this reduces ~90% of the clutter in my logs. (Disclaimer: this may not be the case for you or anyone else)

Just to reduce the crap in the log and also because I can, I have my SSH servers (not saying what their IPs are) using a very effective measure: traffic is dropped from the entire world, except for the CIDR blocks, which I put in ipsets, of the five ISPs over three countries I could reasonably be in when I need to access the SSH servers.

And if I'm really, say, in China or Russia an really need to access one of my servers through SSH, I can use a jump host in one of the three countries that I allow.

So effectively: DROPping traffic from 98% of the planet.

Boom.

Deny by default, allow only those sources that are considered trustworthy. And frequently re-evaluate who and what should be considered trustworthy.

Or close the ports, and install an agent that phones out such as Tailscale or twingate.

Or just Wireguard itself.

This is the way, outbound only connections so you can stop all external unauthenticated attacks. I wrote a blog 2 years back comparing zero trust networking using Harry Potter analogies... what we are describing is making our resources 'invisible' to silly muggles - https://netfoundry.io/demystifying-the-magic-of-zero-trust-w...

I don't want to be able to auth whilst physically in authoritarian regimes. If I had to be physically there it'd be via burner devices.

I used to have an iptables config that just drops everything by default on the SSH port and run a DNS server that when queried a magic string would allow my IP to connect to SSH. It did help that the DNS server was actually used to manage a domain and was seeing traffic so you couldn't isolate my magic queries so easily.

Until there is a new zero day on sshd.

You want to keep these things behind multiple locked doors, not just one.

For the servers themselves, you shouldn't be able to get to sshd unless you're coming from one of the approved bastion servers.

You shouldn't be able to get to one of the approved bastion servers unless you're coming from one of the approved trusted sources, on the approved user access list, and using your short-lived sshd certificate that was signed through the use of a hardware key.

And all those approved sources should be managed by your corporate IT department, and appropriately locked down by the corporate MDM process.

And you might want to think about whether you should also be required to be on the corporate VPN. Or, to be using comparable technologies to access those approved sources.

> For the servers themselves, you shouldn't be able to get to sshd unless you're coming from one of the approved bastion servers.

What if there's a zero-day in your bastion service, whatever that is?