We are seeing significantly more SSH break-in attempts in our server logs lately. What can we do to protect ourselves better?

If possible, restrict SSH logins to specific user/host combinations. If you must leave an SSH login service open to the world then move the service to a nonstandard port. That won’t cure anything but it may slow the attackers down. The Internet Storm Center at SANS is reporting that SSH brute force attacks across the Internet are showing signs of being more coordinated and originating from distributed systems more frequently than in the recent past. Tighten your firewall to limit the number of failed logins allowed from any one system if you can. Eliminate all unnecessary accounts. Use nonstandard names for the accounts that you keep. Ideally you would change the account names to follow good password rules to avoid getting caught by a standard dictionary attack. If you review your logs you will probably see numerous attempts to log in to accounts named root, webmaster, mysql, admin and administrator along with many other frequently used account names. Also be sure to use the strongest passwords you can on the accounts that you do leave open for SSH connections via the Internet. SSH brute force dictionary attacks can easily compromise simple dictionary-based passwords on accounts with standard names on an SSH server running on the standard port. Check your system and firewall logs carefully. And begin the planning now to eliminate SSH services that are open to the entire Internet. As the sophistication of distributed, coordinated SSH brute force door knob rattling increases, the safety of any username/password accessible SSH server decreases. If you can not limit the scope of IP addresses to which you offer SSH services you can at least begin educating users and requiring that they use key-based authentication rather than usernames and passwords. Perhaps this is finally the beginning of the end for the reusable password on the Internet.