I thought about alternatives to fail2ban to deal with brute force attacks against ssh. So far, I only found pam_faildelay.so but it is not documented for hobby admins like me. I put the entry “auth optional pam_faildelay.so delay=2000000“ in /etc/pam.d/sshd and restarted sshd. Without the expected effect. Any ideas?
Sshd has config that might help you.
I played with the options a while ago, but ended up leaving them as the defaults after I locked myself out of ssh!
Set up a VPN, preferably WireGuard, and only open SSH in the VPN firewall zone.
Multi-layered security is the best way to protect against all types of attacks.
Easy. Modify /etc/ssh/sshd_config in order to listen to another port than 22. For instance, Port 1234. Or else, larger than 1024. Then, to connect, ssh yourserver -p 1234. No more attacks, bots are stupid. More details on the procedure for instance here: Change Port in SSH
In the past, I did this, too. But these days, I consider it security through obscurity.
Your system’s security needs to depend on the security of the credentials (the password or the key pair), not on the fact that nobody bothers to run a port scan on your machine. To make this point more obvious, if you have a root password of ‘root’, it doesn’t magically become a secure password just because you change sshd to listen on port 2345. And the other way round, if your password is ‘UA4kg7sRXGAE5g’, go ahead script kiddies, try and log in to that juicy sshd on port 22.
1 Like
It’s trivial for bots to scan for SSH listening on any port you pick.
This is not much of a fix.
I have heard the reverse logic, use that standard port, you get probed and then the bot goes away quickly.
Trivial maybe. Done, never. Try scanning a box with nmap, ss, etc. and tell me the results you obtain in practice. 99% of those attacks are ineffective when changing port. A better measure is to implement knocking, that is, for the OP, to ask the user a procedure than eventually will allow sshd listening on a port. Oh, and first thing first, never allow root to use ssh.
Never, ever allow root to use ssh. A better procedure would be to forbid ssh using a password and rely on keys, better if ed22519.
You missed my point. The user root was just an example. If any user has a trivial password, having sshd listen on a port other than 22 gives you security through obscurity at best.
Of course. But that wasn’t your recommendation that I responded to. If you rely solely on key pairs (even RSA, doesn’t have to be curve 25519) then having sshd listen on another port becomes even more pointless since these cannot be brute-forced with current computing ressources.
There is one valid reason to switch to a different port, though, and that is ressource consumption. If the constant background noise of login attempts that machines on the Internet face puts too much of a burden on a heavily constrained device, then moving sshd off of port 22 can cut down on that load.
If it is never done, how do you explain databases like this?
When I had my sshd on a non-standard port I saw ssh attacks on a daily basis.
1 Like
Thanks for participating in this topic. That we got side-tracked is not a problem. But please allow me a little reminder, because my posting is still without a solution.
I dont intend to defend my choice of a certain method to throttle ssh login attempts. Its my choice. I need your help to be able to help myself. I need documentation for uses of pam_faildelay.so with ssh/pam.
And please excuse my strange choice of words and my grammar.
Did you read the sshd config man page for setting to slow down attacks?
The document is in a man page and you run man pam_faildelay to display it.
delay=2000000 means 2000000 microseconds equal to 2000 miliseconds equal to 2 seconds.
1 Like
Okay, I was too impatient with that manpage. Sorry.
1 Like