Is there a way to automatically block IP address when a user tries to login as any invalid username? I already have:


enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime = 31536000

in /etc/fail2ban/jail.conf

5 Answers 5


First, define the filter for invalid users in filter.d/sshd-invaliduser.conf:

before = common.conf

_daemon = sshd

failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .*? from <HOST>(?: port \d+)?\s*$
ignoreregex = 

journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd

Then enable it in jail.local:

enabled = true
maxretry = 1
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

This works with fail2ban 0.9.6-2 on Debian 9.

  • 1
    This is an excellent answer, incredibly helpful. I augmented the failregex slightly to accommodate additional cases based on my SSH logs, as not everything was being caught. As well as the first line, I also use ^%(__prefix_line)sFailed password for invalid user .*? from <HOST>(?: port \d+)?\s*$, specified on a new line below the first (use spaces, not tabs, to align them to the right hand side of the = equals sign, to avoid python interpreter issues). To test, run fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd-invaliduser.conf. Commented Jun 15, 2019 at 18:17
  • 1
    This is exactly what I was looking for. This takes care of the majority of connection attempts to my host with the general list of users like admin, sally, etc...
    – farhany
    Commented Jul 15, 2020 at 23:17

This is deliberately not supported in fail2ban:

In other words, invalid users may get 2 attempts while invalid password for valid users get 5 attempts. How can that be done in fail2ban?

A convincing argument against doing this says that it lets an attacker know whether or not a username is valid, and thus dramatically decreases the search space of a brute-force attack.

I found your question while trying to do the same thing, but now I've changed my mind. Apart from the secrecy benefit, why save an attacker time by cutting them off early?

  • If they know there is no root user, then they will become aware that the search space is dramatically larger than they had hoped, and may stop harassing my machine by trying to login with that username. In fact, I'd be happy to let them know that there are no users using common usernames on my machine.
    – Diagon
    Commented Jun 28, 2019 at 18:58
  • That answer does not make sense for me: Why give them extra time and spam the log? The point is to delay them, when Fail2ban becomes active, the client that is trying to login is blocked and idealy for a few minutes, but better a few hours (when using an invalid user), because why oh why would I ever try to login as an user that does not exist on the system??? Bots give up when they get blocked by a system for a long time and all the packages get dropped. Since this is all automated, blocking them early is better than waiting, the scanning system does not care for work wasted. Commented Jan 4, 2023 at 3:12
  • There is NO ROOT USER, simply because it is now standard default in all SSH servers to not allow direct root logins, by now everybody should know this, hackers also. Commented Jan 4, 2023 at 4:11
  • Quote: A convincing argument against doing this says that it lets an attacker know whether or not a username is valid, and thus dramatically decreases the search space of a brute-force attack.------ This is no convincing argument at all: It takes the attacker way longer to get blocked on the firewall (via fail2ban) for minutes even better hours than being allowed to bruteforce several unknown users first (which the attacker will be allowed to do) The attacker also knows that many of the users they are trying do not exist on the target system. The value of knowing which ones is therefore NULL. Commented Jan 4, 2023 at 4:15

I cannot help you with fail2ban, but I am using denyhosts quite successfully for exactly this thing. You can tune quite a lot parameters and it also have a distributed database where you can send and receive other badhosts.

Here's more detailed howto:

Install denyhosts package (sudo apt-get install denyhosts)

Look at the default configuration in /etc/denyhosts.conf, you might be interested in DENY_TRESHOLD_INVALID, DENY_TRESHOLD_VALID and DENY_TRESHOLD_ROOT options.

As for the sync server it's disabled by default and you will need to enable it by uncommenting SYNC_SERVER option.

It's also not bad to set PURGE_DENY option to 1w or something like that in case you block-out yourself, so the entry will get purge after one week and you will be able to login again.


Why not just deny all root logins entirely over SSH, rather than using Fail2Ban or other stuff? By doing that, and denying the use of the root login, you remove the issue of having to block everyone, because even if they guess the root password, it'll deny them login. Regardless of how many times they try.

In /etc/ssh/sshd_config, find the line containing PermitRootLogin. Edit that with whatever text editor, but make sure you use sudo/gksudo (gksudo only if you're using a GUI text editor). Make that line I mentioned say PermitRootLogin no, then save, and do sudo service ssh restart.

(This answer was written for the incorrectly-stated initial question. This answer will not be modified to match the revised question, because that's beyond my ability to answer. I may delete THIS answer in future)

  • 2
    I do have that setting enabled however what I'm attempting to do is remove all unnecessary traffic to the server. I'm attempting to have an IP address banned after 3 attempts from using a wrong username, including root. I have had attempts to login with usernames like harry potter, sally... etc. Commented Mar 20, 2013 at 19:35
  • @slayton1213 Based on your comment, I have revised your question and what it is asking, to be more specific to what your actual goal is. Please confirm I got that right.
    – Thomas Ward
    Commented Mar 20, 2013 at 19:41
  • yes this is correct. Commented Mar 20, 2013 at 19:41
  • OK, I can't answer THAT, i only answered the initial question, @slayton1213. I will probably delete this answer in the near future,as a result.
    – Thomas Ward
    Commented Mar 20, 2013 at 19:59

You can Enhance your security by enable roundcube section Roundcube does have captcha plugins available which will mitigate this, but users will complain if they have to type in a captcha to login for mail.

Fail2ban provides an easy solution for this.

First up, we need to add roundcube into /etc/fail2ban/jail.conf


enabled  = false

port     = http,https

filter   = roundcube

action   = iptables-multiport[name=roundcube, port="http,https"]

logpath  = [YOUR PATH TO ROUNDCUBE HERE]/logs/errors

maxretry = 5

findtime = 600

bantime = 3600

Change [YOUR PATH TO ROUNDCUBE HERE] in the above to your actual roundcube folder

eg /home/roundcube/public_html/logs/errors

Next, we need to create a filter.

Add /etc/fail2ban/filter.d/roundcube.conf


failregex = IMAP Error: Login failed for . from <HOST>(\. . in .?/rcube_imap\.php on line \d+ \(\S+ \S+\))?$

ignoreregex =

Now we have the basics in place, we need to test out our filter. For that, we use fail2ban-regex.


  • 1
    What is the relevance of this to using fail2ban for SSH? Commented Nov 12, 2018 at 14:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .