If you take a look at this tutorial it states you'll see a timeout which is consistent with what you're seeing, titled: Fail2ban - Rackspace Knowledge Center.
Let's test fail2ban to make sure it behaves the way we want it to. We'll do that by failing a few ssh logins.
We'll use two machines: The server we want to protect and another machine to act as the attacker.
- Attacking machine's IP: 22.214.171.124
- The server's IP: 126.96.36.199
To run the test, simply get on the attacking machine and try to ssh to your server five times. For example:
$ ssh email@example.com
With the sixth try (assuming you have ssh's maxretry set to 5) your connection should time out if you try to ssh in again.
NOTE: This last sentence is what you're seeing!
Also you can setup
fail2ban to send an email similar to this:
If you have fail2ban set to send you email check to see if you got a message like this one:
From fail2ban@ITSecurity Thu Jul 16 04:59:24 2009
Subject: [Fail2Ban] ssh: banned 188.8.131.52
The ip 184.108.40.206 has just been banned by Fail2Ban after 5 attempts
Here are more information about 220.127.116.11:
Lines containing IP:18.104.22.168 in /var/log/auth.log
Jul 16 04:59:16 example.com sshd: Failed password for root from 22.214.171.124 port 46023 ssh2
Jul 16 04:59:18 example.com sshd: Failed password for root from 126.96.36.199 port 46023 ssh2
Jul 16 04:59:20 example.com sshd: Failed password for root from 188.8.131.52 port 46023 ssh2
Jul 16 04:59:21 example.comsshd: reverse mapping checking getaddrinfo for 184.108.40.206.example.com [220.127.116.11] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 16 04:59:22 example.com sshd: Failed password for root from 18.104.22.168 port 46024 ssh2
Probably the best indication though that
fail2ban worked was the existence of a new
iptables rule that's now blocking the attacking IP address.
Chain fail2ban-ssh (1 references)
target prot opt source destination
DROP all -- 208-78-96-200.realinfosec.com anywhere