Server Security and SSH
patrick — Wed, 2008-03-26 13:38
I was in the phpc IRC channel on freenode the other day when somebody posted a link to My Server has been Hacked. I suggested he switch an option in the SSH server options to require the person attempting a login to have a key. Hopefully he's done this by now.
Most people that deal with remote servers are usually familiar with FTP and/or Telnet. These are both pretty old technologies and were designed prior to the hostile environment that the internet has evolved into. Considering all the security issues around I can't believe that web hosting companies continue to use it and won't allow customers encrypted alternatives!
Basically telnet and FTP transfer everything between the user client and the remote server as plain text. This includes username and password for logging in and all the files you upload & download will be transferred visibly bit by naked bit. Depending on what you're transferring this may be no big deal. If all you're doing is transferring static html pages and you don't care if somebody snags your username/password from logging in then it's a nice fast way to upload & download files. Although in this day and age a lot of people are actually uploading an application of some sort that relies upon a database - in which case your config file will probably contain your username & password for logging into your database server as well... Which means if somebody is watching that file transfer they've snagged both the username & password for both your FTP/telnet server as well as the username & password for your database server!
Most who understand the security implications of this have switched to more secure technologies. SSH replaces telnet and SCP or SFTP replaces FTP. These secure programs are very similar to the encrypted or "secure" web servers (the ones that use the HTTPS protocol instead of the standard HTTP protocol - e.g. the paypal website uses https://paypal.com). The client connects to the server, they exchange a random encryption key, and then they both use the pair of encryption keys to encrypt and decrypt data transferred between them.
While SSH is more secure because of the encryption, most of the default installations from various Linux distros leave it vulnerable to brute force attempts. A brute force attempt is when a person (or computer) tries random usernames and passwords until they're able to gain access to the server. As long as the number of users are small and the passwords are quite long this does make the chances of a successful login attempt almost impossible. Notice I said almost impossible. There's still that chance and that's exactly what happened in My Server has been Hacked.
In order to avoid the average brute force attempt, the sshd_config has some nifty features available. PubkeyAuthentication and PasswordAuthentication allow for some nifty security options. The man pages state that both of these are enabled by default and most of the webhosts that I know of that allow ssh connections also allow for Pubkey (or Public Key) Authentication.
Making sure that PubkeyAuthentication is set to yes and PasswordAuthentication is set to no will cause authentication keys to be required. If the person attempting to login (i.e. somebody attempting a brute force login) does not have a key it doesn't even bother to ask for a password and simply rejects the login attempt.
