It all depends on your constraints and who needs SSH access, but if you're like me, you (1) have a number of personal VM instances on major cloud providers and (2) don't want to deal with anything but 'vanilla' Linux and sshd. No customizing kernels, no portknocking, no TCP wrappers, no fail2ban, no VPNs (not even tailscale which is very nice).
The approach that I've been using for about a decade is a script that gets your current (internet facing) IP and then uses a cloud API credential to add that IP to the cloud provider's firewall as a valid source IP to port 22. The API security and cloud firewall implementation is left to the major cloud providers (and they are very good at these things).
I run it manually whenever I'm in a new location or in the rare cases my home IPs change. You can add the IP to the list or replace the list each time. Or clean it up after a trip with a separate CLI flag. I figured one day I would automate it to track IPs, run constantly, and trigger the change if it detected a new IP - but that day never came because it never annoyed me (ymmv).
This approach could be extended to teams, but there are more details to think through about API permissions, etc.
Can I ask why you don't trust running fail2ban on 'cloud' based VMs? The defaults for how long it will ban failed ssh attempts are quite sensible, and short enough to prevent you from accidentally locking yourself out for a very long period of time (automatic unban time to remove iptables rules).
If nothing else, it serves the useful purpose of stopping the log files from being cluttered up with various botnets' fully automated ssh username/password attempts that are out there, trying to gain access via well known factory default credentials.
It's not really about trust, it's about the hassle of adding and maintaining things (including keeping up with their changelogs and security issues).
As for log clutter, my approach comprehensively stops the logs files from being cluttered with failed attempts; that's one of the main reasons I do it.
That is a good point but I should also add that fail2ban as a daemon and its default configuration to watch log files for other popular daemons (example: a postfix smtp traffic log) has changed very, very little in the past 5-6 years. It's not very much of a concern in terms of keeping track of configuration changes in major system upgrades.
The approach that I've been using for about a decade is a script that gets your current (internet facing) IP and then uses a cloud API credential to add that IP to the cloud provider's firewall as a valid source IP to port 22. The API security and cloud firewall implementation is left to the major cloud providers (and they are very good at these things).
I run it manually whenever I'm in a new location or in the rare cases my home IPs change. You can add the IP to the list or replace the list each time. Or clean it up after a trip with a separate CLI flag. I figured one day I would automate it to track IPs, run constantly, and trigger the change if it detected a new IP - but that day never came because it never annoyed me (ymmv).
This approach could be extended to teams, but there are more details to think through about API permissions, etc.