I like to be able to maintain contact with my servers outside of a few specific ip's - I've locked myself out far too many times when I whitelist a very small number.
Stop using fail2ban/tallow/etc, and follow a sensible guide like https://infosec.mozilla.org/guidelines/openssh to harden your ssh configuration. This will result in about half the attempts failing at protocol negotiation, long before auth (though that ratio is decreasing over time).
Wireguard is also very strong here, as it learned from this kind of problem in SSH and does not reply at all unless authentication succeeds. This makes debugging harder, but also makes leaving it openly listening quite a bit safer, as the protocol surface in pre-auth is absolutely minimal.
I found it harder to use. I even wrote tests for my use cases and what I learned was a real appreciation of what ssh does, is, and provides and I went the other way and use it in more places than I did before.
I don't know the mechanics, but a port knock is hitting pre-defined ports in a pre-defined order. When you "shave and a haircut" the ports properly, the server opens something up. In this case white listing (gray listing?) the IP that the knock came from.
You could add a layers to it to make it more complicated.
Please don't use silly stuff like port knocking. Your SSH server already does a cryptographically sound authentication step. "Port knocking" is even more performative than fail2ban.
I VPN into my home network as a bastion host, so I'm always connecting from the same IP.
I'm using the cloud providers IP filtering to block everything but my IP on port 22. If something goes horribly wrong, I can disable it thru their web interface.
During holiday trips, where I might need to access a server from anywhere, I use a list of one time passwords (more or less just a bunch of md5sums) which I can send to a server on https, which then adds the requesting ip address to /etc/hosts.allow for a limited time. This ip address will be able to connect via ssh (still secured with a key) then for that time.
This is a really cool idea! I've also toyed with a similar approach of watching ssh logs within very specific time windows and providing a one time key in order to temporarily add another SSH key which I can use to recover the server.
Probably a bit overkill - but it was a fun feature to implement with Go over the weekend. The new Fido2 SSH implementation is also incredibly cool.
Anyone have a better workaround for this?