Improve the security of your server by using SSH-Keys

If you want remote access to Linux systems such as Ubuntu on the console level, you can’t get around using SSH. Once the SSH server service is enabled in the system and shared with users, you can log in from anywhere with your normal login data – from home or on the road. But are passwords really secure enough to protect a server’s sensitive data?
The answer is no. Brute-force attacks are becoming increasingly prevalent and more and more effective thanks to longer and longer password lists. But how can you protect yourself against it?
Very easily! Instead of using a password as per usual, there is another possibility: SSH-Keys. These keys, which are based on the RSA encryption protocol, consist of a public key and a private key. The public key is stored on all your systems while the private key remains on your client. You can also protect the private key with a passphrase. So if you now connect to one of your systems, you will no longer be asked for the password of the system, but after the passphrase of your private key. Once you have created such a key pair, you can even disable the login via passwords and make your server even more secure. Gridscale even allows you to automatically place your public key on the servers of your choice. This means that you don’t even have to assign a password.

But first things first. Today, we will give you a step-by-step guide; from creating the key pair to the automated integration of your keys on the gridscale servers.

Creation of an SSH key pair

The first step is also the shortest. The pair can be created with a single command.

ssh-keygen -t rsa

You will then be asked where the key should be stored. Store at the default location by pressing “Enter”.(/home/user/.ssh/id_rsa). You will then be asked if you want to create a passphrase for your private key. This is optional, but it is still highly recommended, so your systems are still protected if ever someone should come across your key. After entering and confirming your password you will see your Public-Key and the Random RSA Pic.

Screen Zielserver


Your Public-Key is now stored in /home/user/.ssh/id_rsa.pub and the private key, which you can easily transfer to other clients, is located at /home/user/.shh/id_rsa. Put the private key on clients that only you have access to.

Providing a Server with your Public Key

Now your server or the system you want to access only needs to know about your public key. There is a very simple command:

ssh-copy-id root@IP-oder-Domain-des-Zielsystems

Then you will be asked for the password. This is the user’s password, in the case of root on the target system. The background is the following: Your client opens an SSH connection to the target system and adds your public key to the ~/.ssh/authorized_keys file there. If it does not yet exist, it will be created. You can also do this manually:

cat ~/.ssh/id_rsa.pub | ssh root@IP-oder-Domain-des-Zielsystems "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Now you can connect via SSH without the password of the server or the target system. If you have created a passphrase for your private key, it is required instead.

Screen Passphrase

Since you no longer need the password, you can also completely block access via SSH with a password. In that case, however, create a security copy of your private key. If something happens to your client, and you do not have physical access to your systems, as is the case with rented servers at traditional hosting companies, you’ll be locked out. If this happens at gridscale, you can simply hang your storage on a second server and store the new public key in the file system. Through the practical system of gridscale it is almost as if you had physical access. So you can expand volumes from different servers and reinstall them somewhere else, for example.

Disable access via Password

To deactivate access via a password via SSH, connect to the relevant system and edit the sshd_config:

sudo nano /etc/ssh/sshd_config

In this file, search for the entry “PermitRootLogin” and change it to “without-password”. It should look as follows:

PermitRootLogin without-password

Now you just need to restart the SSH service:

reload ssh

Fazit

The use of an SSH key is always preferable and much safer compared to a password. However, it is very difficult to get to remote systems once the private key is lost. This should be kept in a secure place.