Just out of curiosity, how many of you guys rate limit your WAN exposed SSH server?
I imagine most don’t do this, but for those who do I am curious what the typical setup is like. I have mine set to 1 attempt every 3 minutes, with public key authentication only.
I use Fail2ban on mine with bantime = 7d which helps to keep the log file at least a little bit smaller.
Are there still people who use passwords on a public SSH server? 
Oh yeah, fail2ban. Forgot about that. I image that is how most people do it since I bet 99% of people here do not have SSH exposed on their pfsense WAN. I wouldn’t.
After posting that message I searched reddit and came to the conclusion that rate limit rules are probably rare. It isn’t a cure all, but it is a nice big road block that helps me feel comfortable having a back door into my network.
I would VPN in and then go in through the front door. Doesn’t help if the firewall is locked up and you can’t get in, but more secure. I would definitely put something like fail2ban on it if it was exposed.
I haven’t either, I VPN in when I need to manage things on my local network while on the road. However, I also have a few VPSs running on which the SSH service is directly accessible from the Internet.
I wouldn’t say that SSH is generally less secure than a VPN, if you are using SSH keys.
IPsec, for example, can be configured in very insecure ways, especially if you connect to older proprietary firewalls with outdated Cypher Suites and outdated KeyExchange mechanisms. There are also still OpenVPN servers out there that are only secured with simple username and password auth, which I would also consider less secure than an SSH server with key auth.
However, VPNs can of course be used more universally than SSH, and if you configure them properly, which is easier to do with modern protocolls like Wireguard, I’d say securitry is more or less equal to a properly configured SSH server with strong keys.
And of course, security should not stop behind the VPN/SSH server. Things like network segregation and strict access rights and permissions can help ensure that the damage is kept to a minimum if someone does get in.
Yep, same here. VPN is the front door, however, I have found the need for a back door on one or two occasions. With that said it has been a long time since that has happened.
Fail2ban works well if you don’t mind extra code. A few lines in nftables does the same thing. Less is more IMO.
I used sshguard back in the day when I had an exposed SSH server.
I was running on a non-standard port. Any error counted, after 3rd failure, a random delay for the source IP was applied. Each failed attempt from there got an ever expanding delay. All failures in the last 7 days counted toward the calculation of the next delay. First delay was 7 minutes plus or minus 2 minutes. Scaling factor was applied to both values.
The server itself was a dedicated bastion server with live logging to another server in the environment and alerting through multiple paths every time any one logged in. It would not do much other than allow a hop to another server with its own separate authentication, and another alert for logins from the bastion server.
I only had this as a just in case I need access to my home systems. VPN or overlay network is a much better solution.