6

I just got an Ubuntu instance on Linode. To secure the SSH on it, I installed fail2ban (using apt-get), but then had a problem: fail2ban kept banning my IP (for limited durations, thankfully) even though I was entering the correct password. So I removed fail2ban and installed denyhosts instead. Same problem, but more severe: It seems like every time I SSH in, my IP gets banned. I remove it from /etc/hosts.deny, restart denyhosts and log in again, and my IP gets banned again.

The only explanation I can think of is that I've been SSH-ing in as root (yes, yes, I know); maybe something is set somewhere that blocks anyone who SSH-es in as root, even if they log in successfully? This seems bizarre to me. Any ideas? (Whitelisting my IP is a temporary fix. I don't want to only be able to log on from one IP.)

Trey Parkman
  • 59
  • 1
  • 3
  • 1
    What SSH client are you using and are you using passwords or keys? I've seen a similar situation with a particular ftp client which would always initially attempt logging in as anonymous and thus very quickly get the ip blocked. SSH doesn't have the same idea of anonymous, but I guess it may be trying to use a key which you haven't authorised or something similar. – WheresAlice Jun 05 '10 at 22:18
  • +1 to kaerast, I run a small hosting company with denyhosts running blocking after 5 attempts. One client actually kept blocking himself, turns out to be a "quirk" with the built in FTP client in Windows. – Natalie Adams Jun 05 '10 at 23:09
  • Using OpenSSH_5.2p1 on my Mac for SSH, and Transmit 3 for SFTP. Using passwords. – Trey Parkman Jun 07 '10 at 17:48
  • Thank you for asking this question!. I asked the same question - but for some reason, was unable to get a sensible answer. I will use the answer you accepted to help me solve the same problem I am having – user35402 Jul 19 '10 at 06:37

6 Answers6

4

I believe I've seen someone say that some of those apps will count failed key logins as a brute force attempt. Do you have an ssh-agent running with keys in it? Connecting with that set will offer every key in turn before falling back to password, so that might be why. Try setting sshd's log level higher, and check fail2ban/denyhost logs.

Edit: here is the original source that tipped me off, with a way to fix it.

Jim Ford
  • 105
  • 6
Daenyth
  • 243
  • 1
  • 7
  • I think you're right. I disabled public key authentication, re-enabled fail2ban, and haven't been banned since. – Trey Parkman Jun 09 '10 at 17:07
  • source url is no longer up archive.org has it here: https://web.archive.org/web/20100809081833/http://od-eon.com/blogs/stefan/fail2ban-and-ssh-public-key-authetication/ – Jim Ford Aug 31 '16 at 15:23
3

please review the following links:

if you wanted to scrap the whole fail2ban, and denyhosts idea, do as Nathan Powell below says, change from port 22 to something more obscure

also a few more ideas:

  1. iptables: the following example will drop incoming connections which make more than 2 connection attempts upon port 22 within ten minutes:

    iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW 
         -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW
         -m recent --update --seconds 60 --hitcount 4 -j DROP

  2. key-based login

  3. port knocker (knockd)

Jeff Atwood
  • 12,994
  • 20
  • 74
  • 92
eric
  • 126
  • 4
1

If sshd is set to VERBOSE logging level (or higher) it puts the phrase '...Failed none...' in the system log whenever a user successfully logs in. By default, fail2ban is set up to count this as a failure. I cured the problem by setting the logging level for sshd back down to INFO.

For details, please see my answer to this question fail2ban bans me after a series of *successful* logins

Community
  • 1
dr-jan
  • 434
  • 7
  • 16
0

if you are sshing as root for a specific reason, i hope you have keys set up. i would recommend these changes to your sshd_config file:

PermitRootLogin without-password
AllowUsers root@ip.add.re.ss

to lock down which host you can ssh into your server as root as.

if you don't need to ssh as root, which there is a good chance you don't, you should set up a normal user for yourself, create a group ssh or something, set up keys for the user, add them to the group ssh and add AllowGroups ssh to sshd_config

then give your user sudo access by running visudo as root, and adding the line: user ALL=(ALL) ALL which will allow your user root access, with your user's password, when running sudo commandX

making sure sshd is locked down would be my first priority, especially if root login must be allowed.

even running on an obscured port, the advanced kiddies will find you with port scanning.

cpbills
  • 2,692
  • 17
  • 12
  • Let's say hypothetically that I need to be able to ssh in as root from anywhere in the world, with a password. Any other things I can do to boost security? – Trey Parkman Jun 07 '10 at 17:07
  • Your best bet then, would be 'port knocking' on my phone, so i can't be more helpful. – cpbills Jun 07 '10 at 17:50
0

If you are open in going back to fail2ban you can always use the ignoreip directive in the jail.conf. For example:

ignoreip = 127.0.0.1 192.168.1.0/32

This way you don't get blocked with your sloppy typing ;-) It also means people can't block you by spoofing your IP (Although with any TCP traffic that isn't to big of a concern).

Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • Sure, but I'd have to do that for each IP that I access it from. Let's assume that I'm a nomadic server admin. I suppose I could add a line every time I SSH in from a new IP, but that's a bit of a chore. And any colleagues I invite to SSH to the site would have to do likewise. – Trey Parkman Jun 09 '10 at 17:06
-2

I think if you are green enough to not be able to solve this by reading the config file and examining the logs, you should aim a bit lower till you get some experience.

If you are optimizing to thwart the brute force attacks that are common, change the port that sshd runs on. That will take care of the vast majority of those.

Nathan Powell
  • 579
  • 2
  • 6