(If you do only use keypairs, you can cut off a lot of SSH probes right away by configuring sshd to not even offer password authentication as an option.)

If only :(

For a long time all my personal servers had SSH exposed to Internet, as they had always been limited to keypair-or-Kerberos (GSSAPI, not the password-emulated one) and I disliked the idea of relying on VPNs – but while disabling password auth does indeed cut off login hammering attempts, it doesn't really prevent the probes themselves – and in particular, it does nothing against bots that make a ton of connections all of a sudden (or against those that send password auth requests despite it not being offered...)

A few times recently, I actually had a machine hit MaxStartups several times when a botnet opened all its connections in the same instant (I think it was 3-4 per address but a fairly large amount in total), shutting me out before they even got to the authentication stage.

I still dislike the idea of requiring a VPN to access even my "entry point" hosts, but I ended up using it for other reasons anyway (as I kept setting up more junk in what passes for my "lab" and of course it only had private IPv4), so at some point I went for it and blocked most inbound SSH from outside.

One semi-related thought was that I've set up a small Dropbear "jump host" (on port 2 because why not) in case of emergencies, and also configured an Apache httpd to act as an inbound HTTP CONNECT proxy for the few odd cases where I might want to connect from a place that blocks SSH (with OpenSSH that involves calling proxytunnel from ProxyCommand while PuTTY supports HTTP proxies natively). If people don't want to VPN and all you want is to block off the botnets, then hiding the servers behind an HTTP proxy might be an effective option – if a very ugly one...

I'm looking at the sshd_config(5) manual page, and can't help but notice that the whole thing seems to be written very matter-of-factly: saying, fairly well, what exactly each option does, while not giving any hint about why the options exist or what they could be reasonably used for.

MaxStartups is a good example. One could easily infer the denial-of-service behavior that's not stated outright. But how was the default value of "10:30:100" chosen? What determines whether a value is reasonable in some environment? When should I use the "random early drop" feature? Why does an unauthenticated-connection limit exist at all? Likewise for LoginGraceTime, how would a too-low number affect user experience?

My guess is that these two options exist because there's significant cost to keeping an unauthenticated connection around. I suspect OpenSSH's famous "privilege separation" feature might be making things costly compared to the servers that could handle 10,000 clients ("the C10K problem"), 25 years ago, on a 1 Gbit/s connection. But Wikipedia says that a single server can now handle millions of connections. Without any sense as to what the cost of an unauthenticated OpenSSH client is, I really have no idea whether the default limit is still reasonable or has become terribly dated. Maybe I should multiply it by a thousand. Maybe OpenSSH should be re-architected till it can reasonably handle 10,000 or 100,000 ("openssl speed ed25519" shows that my server can verify upward of 10,000 signatures per second—but "top" suggests that's single-threaded, and this is a 16-core 32-thread system!).