Years ago when I got my first server I remember installing some scripts to check its integrity and warn me about attacks. I was amazed and quite frightened by the number of SSH attempts. I soon learnt, however, that this was quite normal. It maybe worrying, but it's normal.
Put a server on a public IP and people will try to crack it.
There's no avoiding that. Well, there is, but it's a bit impractical to disconnect a web server from the internet :)
So what can you do?
One of the solutions is to use iptables to block the IPs of failed login attempts. If someone (or something) makes more than X connection attempts from a particular IP then you block it.
Of course that's easy if you can program. I can't!
Luckily I don't have to, as there are solutions like the rather excellent Fail2Ban available:
Fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.So not only can you block SSH attacks, you can also use it to defend yourself from other bruteforce attempts. There are debian / Ubuntu versions available, so all you need to do (as root) is run:
apt-get install fail2ban
This will install the daemon and its basic config, which is to silently block SSH attacks.
You can easily customise the configuration by editing /etc/fail2ban.conf
The developers have left nice clear comments in the file, so even I was able to make the necessary changes, including whitelisting my own IPs ie. you don't want to lock yourself out just because you've forgotten your login details.
There's also a nice writeup here which goes into some depth about the various options available.
There's a /way/ simpler way to stop the brute force attacks: change the ssh port. 99.9% of the scans are done by bots, which don't port scan. Suck it and see, I guarantee they'll disappear immediately. Of course this is only of use on private servers, or where you have customers with clue. :)
Adam
Security through obscurity isn't my thing
Michele
It isn't security through obscurity Michele, it's a way of stopping the automated bot attacks. Like I said. This with disabled root logins and a good password policy negate the need for anything else. But hey, if you want to keep trawling through garbage in your logfiles, work away fella.
I change the SSH port of any public facing machine I have. It means alot less crap in /var/log/secure to look through
You could also just not run ssh on a public facing port. Setup an IPSEC or SSL VPN, and run sshd only on an internally accessible/vpn accessible port...
If you've got a real network instead of just a colocated box somewhere, I just dual-home my machines, and only run management stuff on an entirely separate interface, and don't expose anything to the world that they dont need to see.
Looks very similar as denyhosts.
I like to use iptables limit option.
Something like:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 2/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset
Will reject any ssh connections after 1 failed ssh session for 30 seconds. It works fairly nicely. The only problem is connecting to the host from a dynamic IP during an ssh attack. Static IPs are fine since you can create a rule which gets matched before the rate limiting rule.