I tried to block myself from my own server to test if fail2ban works correctly, so I tried ssh login and used a wrong password over and over. But I was blocked only after 13 failed logins instead of the default 6 fails.

I removed fail2ban with --purge and reinatalled it, so there should be the defaults in /etc/fail2ban/jail.conf now. This is how it looks at my server:


# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip =
bantime  = 600
maxretry = 3


enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

So as i understand, for ssh there should be maxretry 6 now. Why could i try 12 times without being blocked?

I also tried a brute-force attack with THC-Hydra:

hydra -l john -P /tmp/pass.txt myserver.de ssh

and there I saw in /var/log/auth.log that hydra tried 20 to 30 attempts in a row without being blocked. see my log here: http://pastebin.com/PuMdfU2H

some more information:

i uninstalled fail2ban and then I got some messages in /var/log/auth.log during my hydra attack like

sshd[9286]: Failed password for john from 123.456.123.456 port 54705 ssh2
sshd[9286]: Failed password for john from 123.456.123.456 port 54698 ssh2
sshd[9280]: PAM service(sshd) ignoring max retries; 5 > 3
sshd[9286]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= 
sshd[9285]: PAM service(sshd) ignoring max retries; 6 > 3

maybe ssh is redirected on another port each time?

I didn't get blocked this time, so fail2ban is kind of working, if installed.

  • Have you defined jail options?
    – sh4d0w
    Dec 17, 2012 at 9:27
  • which option do you mean? I already stated the options in /etc/fail2ban/jail.conf. 12 is such a number it could be added up two maxretry options of 6?
    – rubo77
    Dec 17, 2012 at 9:48
  • but no, i checked that. it seems to be after a random number of retries, that I am blocked. last time it was after 20 retries
    – rubo77
    Dec 17, 2012 at 10:17
  • I think bantime = <value> is missing from the definition of ssh options.
    – sh4d0w
    Dec 17, 2012 at 11:00
  • No, the bantime is taken from the default, if missing. must be something else, i added more information to the question: log in pastebin and maybe a hint
    – rubo77
    Dec 17, 2012 at 12:02

1 Answer 1


I think you are seeing a combination of two things:

  1. Latency between the time sshd sends the string to the log, the time syslog writes it to the disk, the time fail2ban picks it up, parses it, and and injects an iptables rule into the running set, and the time the kernel starts paying attention to the new filtering rules. This is why you see "Already banned" entries in fail2ban.log.
  2. PAM, login.defs and sshd all trying to block successive retries. If you notice, it says sshd[9280]: PAM service(sshd) ignoring max retries; 5 > 3, which PAM telling you that there is "retry=3" in one of its modules (probably /etc/pam.d/password-auth) and it will ignore any further authentication requests from sshd within the same session. Sshd will continue trying until it exhausts MaxAuthTries setting (default is 6, I think), at which point it will terminate the connection. This probably creates different log entries that fail2ban doesn't parse as failed login attempts. Just a guess on this one.


You must log in to answer this question.

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