blacklist hosts after 3 wrong password

Bug #77943 reported by Emmanuel Touzery
8
Affects Status Importance Assigned to Milestone
pam (Ubuntu)
Confirmed
Wishlist
Rick Clark

Bug Description

I don't install sshd on my system because I'm afraid of people brute force cracking my password, like in bug #58074.
my password is weak, because it's the password I use to login on my computer and I must remember it. I didn't find a way to set another password for ssh than my password on the computer.

I think that ssh should have an option, enabled by default, to blacklist hosts if they enter more than 3 times in a row the wrong password. It should be easy to re-enable their connection by modifying eg /etc/sshd/blacklisted-hosts.txt

and when a host is blacklisted, it should be logged so that the user can diagnose how come the remote SSH is no longer working. blacklist entries could expire after 3 months for instance (to avoid ever-growing blacklist files).

I think I read somewhere that it works like that on Mac. certainly I don't see a big flaw in this approach and it would be much more secure than the current approach.

Revision history for this message
Andrew McCarthy (andrewmccarthy) wrote :

You can achieve roughly the same thing already using the "fail2ban" package, which adds temporary iptables rules when it sees enough failed attempts on ssh (and other services).

Revision history for this message
Emmanuel Touzery (emmanuel-touzery) wrote :

Thank you, I didn't know about the fail2ban package. Maybe i'll try it (i wonder if it works immediately after install, or needs manual configuration to enable it?).

anyway, if it works it's true that it could be good enough to have an external package (as is the case now) to do that, since ssh-server is not installed by default and since only more expert users install ssh.

Revision history for this message
Brian Murray (brian-murray) wrote :

You might also investigate using public and private key authentication and turning off password authentication. This would reduce the possibility of brute force attacks. You can learn more about key authentication here: https://help.ubuntu.com/community/AdvancedOpenSSH#head-f06532af79917a251e68c7ccf567cb5c399e0aba

Revision history for this message
Albert Bicchi (bicchi) wrote :

I am running Ubuntu server edition and was surprised to see so many attacks on my /var/log/auth.log*

# zcat /var/log/auth.log.* | grep Failed | less

I think if Ubuntu wants to push the server to the next level it must ensure security, reliability and speed. Is there a reason why and IP blocker tool is not integrated with the sshd daemon?

Should I open a feature request and propose this on Feisty+1 or do you think that this is something that the sysadmin should configure him/herself if needed?

We could use the fail2ban tool suggested above but these are other tools that seem to do a similar job. Unfortunately we do not have packages for any of them:

sshguard:
http://sshguard.sourceforge.net/
http://www.linux.com/article.pl?sid=07/02/27/1957242

BlockSSHD:
http://blocksshd.sourceforge.net/

sshdfilter:
http://www.csc.liv.ac.uk/~greg/sshdfilter/

Martin Pitt (pitti)
Changed in openssh:
importance: Undecided → Wishlist
Revision history for this message
Micah Cowan (micahcowan) wrote :

Using a crappy password for an important service because it needs to be easy to remember is a very, very bad idea. A much better idea is to choose a difficult-to-crack password, and keep it in your wallet.

While it takes some setting up, as long as you're keeping things in your wallet you might look into setting up OPIE (S/KEY) for your server. It uses a short pass phrase, that changes every time you log in. Practically impossible to crack, and renders keyboard sniffing useless.

Many sshd users, because of the constant crack attempts (my logs are filled, too), opt to choose a different port for their servers to sit on. This pretty much eliminates the attacks.

Personally, I use key-based authentication, with a failover to OTP. I keep a list of the passphrases in my wallet.

Revision history for this message
Rick Clark (dendrobates) wrote :

The functionality to do this is in pam_tally. I am changing the package to pam, as this is not openssh specific.

Rick Clark (dendrobates)
Changed in pam:
assignee: nobody → dendrobates
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.