2

We have a Ubuntu 14.04 server which is running Plesk 12.5. I have an issue where SSH connections appear to get blocked, and I can't figure out why.

If we do a dozen connections over a short time period (less than a minute) (all with correct details, login and work fine) then they start to be refused. It appears to be limited to the ip address since I can ssh in fine from a different location.

This happens with different users of the system, and once that ip has hit the limit (if that is what it is) no user on that same ip can login.

When it's blocked, I have checked IPTables, and there is no entry in there. I have grepped the whole of /var/log/ for the ip, and nothing found there either.

Where on earth could it be getting limited?

Edit Fail2Ban is on the server, but nothing in the logs (or IPTables), and all the the connections are with correct details, so shouldn't trigger an error.

This is on a VPS, I would doubt there is a firewall in front of it.

Wizzy
  • 21
  • 3
  • Too little information. Are you running something like `fail2ban` on the machine? Is there anything in the network between the server and the ssh client, like a router or firewall? – Tilman Schmidt Sep 16 '16 at 09:57
  • @TilmanSchmidt updated – Wizzy Sep 16 '16 at 10:03
  • Is your ssh server running via xinetd? Can you also reproduce this on localhost only? – rudimeier Sep 16 '16 at 10:11
  • @rudimeier yes it is running that. I have not tried local host only. – Wizzy Sep 16 '16 at 10:38
  • 1. Note that providers' management interfaces like cPanel or Plesk are explicitly declared off-topic on ServerFault for a reason. 2. It is not uncommon for a VPS to have a firewall or rate limiting device in front of it. 3. It is perfectly possible to configure fail2ban to trigger on successful logins too. 4. Both fail2ban and iptables may log somewhere else than you're expecting, or not at all, especially on a VPS. In sum, your first step should be to find out where exactly the ssh connections are being blocked, by adding logging for successful connections in strategic places. – Tilman Schmidt Sep 16 '16 at 21:10
  • Did you end up fixing this issue? I am having the same problem. – Mattigins Apr 13 '17 at 07:32
  • No I didn't resolve it @Mattigins I just slowed down the script so it doesn't hit ssh so fast. – Wizzy Apr 20 '17 at 21:49

1 Answers1

0

I was having similar problems. You mentioned checking your iptables, just to make sure see if you have hitcount set, something similar to this (2nd line):

Chain INPUT_direct (1 references)
target     prot opt source               destination
           tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
REJECT     tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW recent: UPDATE seconds: 30 hit_count: 4 name: DEFAULT side: source mask: 255.255.255.255 reject-with tcp-reset

The key parameter is hit_count and also take a look at UPDATE. In my case I was getting rejections after 3 tries, and nothing in the logs either.

You can also always add your ip into the ignoreip list in your fail2ban jail.local config file.

Levon
  • 113
  • 1
  • 1
  • 6