Jonathan E. Ross

SSH Server Security Guide

Jonathan E. Ross -

Although SSH is itself a secure protocol, the standard password based login mechanism is weak. Allowing password based logins via SSH poses severe security concerns, mainly from brute-force login attempts. To combat this concern, one would have to ensure that all passwords for login accounts on a system are complex enough to withstand these attacks.

The only proven method for securing password based ssh logins is to simply not allow them at all. Instead, users are required to login with an RSA public key pair. The concept is rather simple, but the strength of this access mechanism comes from the following:

  • A user needs to have a key
  • The key needs to be authorized on the server
  • The key requires a pass-phrase to be used

THEORY

The RSA key pair has two parts, a public key and a private key. The public key is like a special lock that only the private key it was generated with can unlock. So a system can have hundreds of public keys (locks) and every user has a unique key to the system (their private key). Their private key also requires a pass-phrase to use.

A successful login requires a user to have their public key (their custom lock) installed on the remote server. They also need to have their private key (their key) on the system they are connecting from. Finally, they need to enter a pass-phrase to be able to use their private key (their key) to match the public key installed (to unlock their custom lock) and gain access to the system.

It is because of these three requirements that using RSA key pairs to login over SSH eliminates the susceptibility of a server to brute-force attempts. It is also the only method to effectively secure SSH servers on which multiple people log in.

IMPLEMENTATION

Securing an SSH server by using key-based authentication involves a few simple steps:

  • Generate the key pair
  • Install the public key on the remote server
  • Verify login with key
  • Change the SSH server configuration to deny password-only authentication

GENERATE KEY PAIR

This should be done on the system you will be using to connect to your remote server. This could be your home computer, for example.

First, generate a location for the keys to exist by running the following command in a terminal.

mkdir ~/.ssh/

Next, generate the keys inside this directory

cd ~/.ssh/
ssh-keygen -t rsa -f mykey_rsa

Note that the -f allows you to specify a filename. If omitted, it will default to whatever is specified in /etc/sshd/sshconfig. Typically this would be id_rsa.

Note that two files were generated: mykey_rsa, and mykey_rsa.pub. The .pub file is the public key. This is the "lock". It will be installed onto each remote server that you need access to. This file is safe to transport over networks, as opposed to the other file: the private key. The private key should stay on the host used to connect to remote servers. It should never be transferred to other systems.

When prompted, enter the pass-phrase desired. This creates the “key” part that was discussed in the above theory. Do not leave the pass-phrase blank. This can technically be done but should only be done under very special circumstances which will not be covered in this guide.

Now, configure your computer to use this as your “Identity” when connecting. Create the ~/.ssh/config file and insert the following line inside it.

IdentityFile ~/.ssh/mykey_rsa

Finally, secure the ~/.ssh directory by running the following:

chmod o-rwx ~/.ssh/ -R
chmod g-rwx ~/.ssh/ -R

INSTALL THE KEY PAIR

Next, the public key (the .pub file generated above) needs to be installed on the remote server. Begin by transferring the key from your system to the server:

scp mykey_rsa.pub server:~/.ssh/

Once the public key is on the server, append the key to an authorized_keys2 file. This file tells the server what keys are authorized to connect to the server using that user account.

cd ~/.ssh/
cat mykey_rsa.pub >> authorized_keys2

Ensure the permissions are correct, then cleanup the directory:

chmod o-rwx authorized_keys2
chmod g-rwx authorized_keys2
rm mykey_rsa

VERIFICATION

Now we are ready to verify the key allows us to login. Simply SSH into the server with the following command:

ssh server

If the public key and private key are properly in place on both the server and your system, respectively, you should be prompted for your pass-phrase. After entering it successfully, you should be connected to the server.

SERVER AUTHENTICATION SETTINGS

This final step should only be performed if you can login successfully to the server using your SSH key. If you cannot do so and you proceed further, you will lock yourself out of your server. This would be very bad if physical access to the server was not feasible.

Begin by editing the SSH server configuration:

nano /etc/sshd/sshd_config

Locate the following lines in the file and adjust to match as necessary.

PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys2
PasswordAuthentication no

Now restart the SSH service:

service sshd restart

Finally, before you disconnect, verify that connecting to the server using your SSH key still works. Also, make sure that connecting without a valid SSH key will fail.

FINAL THOUGHTS

The current state of computer security indicates that every internet-facing SSH server is guaranteed to be subjected to brute-force login attempts. It is therefore imperative that SSH servers are configured to prevent these attempts from being successful. Failure to do so will only postpone the day your server gets hacked.

There are many effective ways to secure an SSH server. The instructions presented above can be followed if one has a desire to use public key mechanisms to secure their SSH server.