On most of my servers that allow ssh, I use keys only and disable passwords. I don't worry that my passwords will be guessed anytime soon as they are all long and random, but I very much like that my logs don't fill with that crap.

One of the first things I do when setting up a new VM is install DenyHosts:

http://denyhosts.sourceforge.net/

The out of the box config options are pretty decent, giving a few attempts to most accounts but only one wrong password for root before blocking the IP address.

I have it send email notifications to my support ticket tracking system, which automatically sorts them so I can see how heavily I'm being attacked at any given time, or if one VM in particular is being targeted. (One VM has been a particular target over the holidays, so I just turned off SSH entirely and access it using the Xen console for now.)

The down side of having a good understanding of how much you're under attack is that it is a bit disturbing. In reality, I know that I could just leave SSH running on all my VMs, but turning it off when someone's targeting one of them reduces the flow of scary emails. The most disturbing thing is how many machines these guys must have already compromised, since as soon as you block one IP address another steps in.

I use ssh on a non-standard port, not for security, but to avoid all the annoying attempts in the logs.

I use ssh keys only. I've disabled the use of passwords for any account other than root on the console, and for that, I use a very long random password which is stored very carefully, encrypted with a long passphrase. This is only needed in emergencies.

Be careful to protect your ssh keys (long passphrases and ssh-agent), and it's probably a good idea to use hashes in your known_hosts file rather than addresses so malware can't find all the hosts you can access.

Yeah, my setup was already pretty secure; and I ended up just switching to a non-standard port for cleaner logs.

But since then I haven't spotted a single brute-force attempt on any of my boxes...

There are good ways to prevent getting rooted, as you say, but I know exactly what you mean. The first time I set up a virtual server, someone began a dedicated brute-force, dictionary attack against ssh within 30 minutes. The attack wasn't particularly aimed at me, of course, since I had an empty virtual machine on an ip number that I had been given only a half hour earlier. Still, it's a bizarre thing to watch the logs and see some machine hammering at your door (even if you believe the door to be very solid). The attack went on for over 12 hours, for whatever that's worth. It felt damn scary the first time - even though I knew that I had absolutely nothing of consequence in the server yet (brand-spanking new) and that I could wipe the whole setup and start fresh with nearly zero effort. Nevertheless, it was creepy. It's sort of like being in a horror movie: you simply watch and listen as the monster pounds on the door. (Of course, you have a lot more options than the twits in the movies, and your monster is usually either (1) a pimply-faced kid in suburbia or (2) a cyber-criminal who doesn't much care where he gets in and happily moves onto the next ip in short order. But the initial feeling was like that.)

Like most of the other posters, I ended up taking the following steps to cut down on the problem: (1) disable root login at all, (2) switch sshd from port 22 to another, random port for listening (that alone cut the attacks way, way down), (3) disable all password based logins; only key-based logins work now, (4) limit the users who could login remotely at all to a very small group (you can create a group just for this purpose, enroll two or three admins and edit your sshd_config file to allow only members of that group to login at all), (5) use rate-limiting in iptables to freeze out any attacking ip after two or three failed attempts in a minute.

A link with lots of detailed methods to handle brute force attacks and their pros and cons, in case anybody wants it: http://la-samhna.de/library/brutessh.html

fail2ban solves all our problems. We only get about 5 hits a day total on each host now.

http://www.fail2ban.org/wiki/index.php/Main_Page

Thank you for pointing me to this. Looks very useful.

Yes - three simple things to mitigate risk: 1)Run ssh on non-standard port 2)Disable root login PermitRootLogin No 3) Only allow specific users ssh acces via AllowUsers directive

"On the back of a napkin, so to speak, and with a number of reasonable assumptions, I calculated that it would take 2.2098499729010715e+28 years to do so, with a 1,000,000-strong botnet constantly hammering away." (That's with a 20-char root pwd. Just make your root pwd strong.)

[1] http://www.mollison.us/blog/2009/10/18/how-hard-is-it-to-bru...

1. Disable root login. 2. Disable passwords.

There's no excuse for root logins and passwords are harder to manage and less secure.

I also limit port 22 or whatever to, say, 3 tries a minute (iptables) just so you don't look like low-hanging fruit

something like this

http://jonsbraindump.blogspot.com/2007/09/iptables-rules-to-...

i just saw this on HN, a SSH blacklist

http://isc.sans.org/diary.html?storyid=7855

I use the ssh blacklist utility and it works pretty well. Although it opens up the IPs after 4 days (default), which I don't really liked, so I pumped that up to 14 days which seems to work nicely.

You can use iptables to rate limit connections:

  -N SSH_RECENT
  -A INPUT -m state --state NEW -p tcp --dport 22 -j SSH_RECENT
  -A SSH_RECENT -m recent --set --name SSH
  -A SSH_RECENT -m recent --update --seconds 60 --hitcount 3 --name SSH -j DROP

> moving ssh to a non-standard port number

+1. If/when there's an sshd remote exploit/worm, it will probably only scan port 22.

"AllowUsers" is good too.

And, port knocking if you don't mind the hassle.

ossec hids got active response and other cool helpers.

I started running ssh on port 443 when public ssh is required, because it works more reliably when traveling. A nice side effect is that it also avoids the Rumplestiltskin attacks.

That said, my preferred solution is openvpn.