Configuring Your Linux Server to Use SSH Key-Based Authentication

SSH on a Linux Server

SSH, also known as secure shell, is a protocol that can be used to connect and communicate with a server. You can connect to your Linux server for a terminal session using this encrypted protocol. If you are using an OpenSSH server, there are primarily two different ways you can go about the authentication process. The first one is your standard password-based authentication. Here, you simply use your username and password credentials to gain access to your account. The other way is to set your Linux server up for SSH key-based authentication.

In this guide, we will focus on how you can configure your Linux server to use SSH keys as the primary means of authentication. We will also discuss why SSH keys are often preferred over the usual password protection mechanism.

What are SSH Keys?

SSH keys are similar to the credentials you would use to login to your account on the server. Instead of entering your username and password, you use the SSH key pair, which is also an access credential. While the keys are cryptographic, you must treat them as authentication credentials since that is the purpose they serve.

A typical SSH key has two parts: an authorized key and an identity key. The authorized key is the public key which works in combination with your private identity key to give you account access. The public key is located on the remote server that you want to log into with SSH and remains in the ~/.ssh/authorized_keys file associated with your user account. Identity keys serve to verify your identity as the correct user to ensure only authorized personnel can access the given account. Collectively, these keys are called the user keys as they authenticate the identity of the user. Once the server is able to verify both keys, a shell session is initiated in order to execute your commands.

You also have host keys and session keys. The protocol authenticates the local computer, system, or server using the host key. Session keys help to encrypt the data stream over the connection. This makes your session and corresponding activity much safer and secure.

SSH Keys Over Password Protection

The main reason why SSH key-based authentication is preferable over password protection is that the latter can leave you vulnerable to cyber-attacks. Most individuals do not use extremely complex passwords so that they can remember them when they need to log in. As a result, this creates an area of vulnerability. Many attackers employ force to break the relatively simple password and crack into the account. This has become particularly easy these days because of automation and advanced hacking technologies.

SSH keys, on the other hand, offer a much more secure way to gain access to your account. As we mentioned before, this method uses a public key and a private key to authenticate the identity of a client. While you can share the public key with anyone, you need to keep the private key a secret. When paired together, the public key decrypts the private one to authenticate your identity. Furthermore, you can layer on the protection by adding a passphrase on top of the key pair. We will talk more about the passphrase further on in the guide. However, even without the passphrase, your private SSH key is kept extremely safe on your local computer. The network is never able to directly access the key, which is located in a restricted directory and is supplemented with restricted permissions.

Generating SSH Keys

To generate your SSH key pair, you need to browse through the OpenSSH suite of tools and locate ssh-keygen. This is a special utility tool that allows you to generate an SSH key pair that is around 2048 bits large. Begin by running this command:

This will prompt the following message:

The message will generate a private key named id_rsa and a public key named id_rsa.pub. At this point, you can choose where you want to locate the key. We would recommend staying with the default location by pressing Enter. Sticking with the default location ensures that the server will automatically locate and verify the keys whenever you log in using that system. The default location is the ~/.ssh directory in the home directory. If you prefer to select a different place, type in the location.

Rewriting Older SSH Keys

It is important to note that you can have only one SSH key pair on your system at a time. This means that if you have previously generated and saved a key pair on the system, you will see the following message:

To continue creating and saving your new SSH key pair, you must delete the existing one. Remember: if you overwrite the key already saved on the disk, you will not be able to use it for authentication purposes anymore. This is an irreversible process, so make sure you are absolutely certain that you wish to overwrite the old key pair.

Setting a Passphrase

Once you have set up the keys in the directory, you will be asked if you want to supply a passphrase:

The passphrase is optional- you can choose to skip it. However, it adds an extra layer of security for your private key by encrypting it on the disk. If you choose to use a passphrase, you will have to enter it correctly every time you attempt to log in using this SSH key pair:

Finally, you should now have your SSH keys that you can use to authenticate the client.

Embedding Your SSH Key Into Your Server Account

Before you use the keys for authentication, you need to embed the public key on the remote Linux server. Next, we will show you how to do that when creating your CloudSigma server. First, you need to find your public SSH key so that you can copy and paste it. If you have used the above method to generate your SSH key pair, you can find the public one by typing the following:

This will result in the public SSH key popping up like this:

Copy this value to use later. When creating a server with CloudSigma, you have the option to add an SSH key after you have selected the server size and OS image:

Click on Add and paste what you have copied to embed the SSH key into your server. As a result, every time you boot your server, it will already have the injected SSH key.

Copying A Public Key To An Existing Server

While the above method works for when you are creating a new server, is it possible to embed an SSH key into an existing server? The answer is yes and there are multiple ways you can go about doing so depending on what tools you have at your disposal.

Using SSH-Copy-ID

This is the simplest and easiest way to copy a public key. All you need is the ssh-copy-id utility tool that you will find in the standard OpenSSH suite. But before you put this method to use, make sure that password-based authentication is activated on your server. To copy the key, you will apply the ssh-copy-id syntax and then enter the remote host that you wish to connect to. You will also have to specify the account you are connecting to. You need to have password-based access to the account, so that your key is copied at the right location. The command should look like this:

This may result in a message like the following popping up on your screen:

This typically happens if it is your first time connecting to that particular remote host. It simply means that the computer failed to recognize the host. All you need to do is type ‘yes’ and press Enter. Once you do that, the tool will scan the account to find your public key. Upon locating it, it will ask you to enter your account password:

Next, you can enter your password. When you are connected to your account, the tool will copy the material of the ~/.ssh/id_rsa.pub key and paste it under authorized_keys in the ~/.ssh directory on your remote account. You will then see the following message:

This means that you have successfully copied your public key onto your existing remote server.

Using SSH

This is a rather conventional method to copy your public key onto a server. It is preferable to use it if you do not have access to the ssh-copy-id tool. Again, you need to have password-based access to your account. What you are essentially doing is putting the content of the public key as an output on your computer and transferring it to the remote server through the SSH connection established between them. The command you will use for this purpose should be as follows:

As you can see, we have specified that the key should be placed in the authorized_keys file within the ~/.ssh directory on the server. Using the >> symbol also ensures that we are adding keys instead of overwriting them. After running the command, you may see this message:

Similarly to the previous message, this means that the computer did not recognize the remote host. Type in ‘yes’ and press Enter to move on. Now, you will enter the account password:

Once the password is verified, the key will be copied to a file in your user account as specified.

Manually

In case you do not have password-based access to your account on the remote server, you can copy the public key manually. The goal is to get the value in the id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote device. As we already know, we can visualize the value of the id_rsa.pub key by using this command:

The content of your SSH public key will appear like this:

Next, you need to gain access to your account on the remote host through whatever means available. When logged in, check to make sure that the ~/.ssh directory is present. If not, you can run the following command to create it:

Now, you can use this command to add the content of the id_rsa.pub file to the authorized_keys file in this ~/.ssh directory on the remote server:

Instead of typing ‘public_key_string‘ in this command, you will have to enter the content of the key that you extracted by running the cat ~/.ssh/id_rsa.pub command previously.

Authentication With Your SSH Key

Now, you can easily enter your account using only your SSH keys. This means that you no longer need your password to gain access to your server account. You will use the credentials that you typically use for login purposes:

This may cause the following message to pop up:

Do not worry if you see this message. It simply means that the local system is unable to recognize the remote host. This usually takes place if you are connecting to the host for the very first time. All you need to do is type ‘yes’ and press Enter. Going back to some of the previous steps, if you applied a passphrase, this is where you will have to enter it. If you did not, you would log into your account straight away after the SSH keys are authenticated. This will prompt the opening of a new shell session through your current account on the local computer.

How To Disable Password Authentication On Your Server?

Now that you know how to set up your SSH keys, you need to disable password authentication. Even if you are able to use the SSH keys for authentication, you are still vulnerable to brute force attacks if your password authentication process is active. Before you disable the password authentication mechanism, make sure that the configuration of SSH key-based authentication is of the root account on the server or that the configured account has sudo access. The reason to confirm this is to make sure you retain administrative access to the account even when passwords are disabled. Now you can use this SSH key to log into your server account. The next step is to open the SSH daemon’s configuration file:

Here, you need to search for the following directive:

You need to uncomment this line and turn the value into ‘no’, as follows:

Doing this will disable password-based authentication. Simply save the file and close it when you finish. Lastly, you need to restart your device to apply the changes. If you are the user of an Ubuntu or Debian device, you can also use the following command to disable password-based entry:

To make sure that your daemon, or sshd, only allows for SSH-based authentication on the server on CentOS or Fedora machines, use the command:

Conclusion

Once you have completed all of these steps, you should have SSH key-based authentication configured and running on your server.  Now, you can rest assured that your servers are safe and protected!

Happy Computing!