The advantage of the method described is its fairly easy with less
> dependencies. In my opinion the rate limit should be per IP rather than
> for everyone which is possible in iptables (look it up yourself). Also
> recommend reject rather than drop as the iptables target so users know
> the connection is over rather than just timing out.
Thanks for the suggestion. The problem that I am finding with the method in
the URL are:
1. It doesn't block actually, it reduces the number of possible trials.
Still the intruder can try 8 times.
2. It blocks only ssh. It doesn't block the IP from accessing all the
ports in our server.
3. As per your suggestion, if it should be per IP, then it will be
difficult to automate it. We need to find which IP first.
> The advantage of fail2ban is;
> * it works of methods other than ssh
> * it blocks the IP where the failed authentication attempt originated
> while allowing other users to connect at a full rate.
Yes, I saw these things in my study. The advantages that I found are:
1. Easy to maintain and configure.
2. Blocks IPs for all the ports and services (other than ssh).
3. fail2ban internally uses iptables, but for some reason the
that the other method is better. May be it is because of the log
4. Does not rate-limit or block ourselves.
> If you after a simpler protection just for ssh recommend disabling
> password authentication on it.
Yes I am already using the ssh keys. But I am seeing a lot of ssh
connection trials in my /var/log/auth.log. So I thought of ways to avoid
this. (Like an additional security). Also I have some chrooted sftp users
too. They don't use sshkeys.