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: 184.108.40.206
- The server's IP: 220.127.116.11
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 18.104.22.168
The ip 22.214.171.124 has just been banned by Fail2Ban after 5 attempts
Here are more information about 126.96.36.199:
Lines containing IP:188.8.131.52 in /var/log/auth.log
Jul 16 04:59:16 example.com sshd: Failed password for root from 184.108.40.206 port 46023 ssh2
Jul 16 04:59:18 example.com sshd: Failed password for root from 220.127.116.11 port 46023 ssh2
Jul 16 04:59:20 example.com sshd: Failed password for root from 18.104.22.168 port 46023 ssh2
Jul 16 04:59:21 example.comsshd: reverse mapping checking getaddrinfo for 22.214.171.124.example.com [126.96.36.199] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul 16 04:59:22 example.com sshd: Failed password for root from 188.8.131.52 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