Tutorial Configure SSH Key-Based Authentication on a Linux Server

SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with a Linux server, chances are, you will spend most of your time in a terminal session connected to your server through SSH.

There are a few different ways of logging into an SSH server, but in this guide, we’ll focus on setting up SSH keys. SSH keys provide an easy, yet extremely secure way of logging into your server. For this reason, this is the method we recommend for all users.

Tutorial Configure SSH Key-Based Authentication on a Linux Server

Join us with this article to learn how to configure SSH Key-Based Authentication on a Linux Server.

How Do SSH Keys Work?

Firstly, we would see how do SSH Keys works basically?

An SSH server can authenticate clients using a variety of different methods. The most basic of these is password authentication, which is easy to use, but not the most secure.

Although passwords are sent to the server in a secure manner, they are generally not complex or long enough to be resistant to repeated, persistent attackers. Modern processing power combined with automated scripts makes brute-forcing a password-protected account very possible. Although there are other methods of adding additional security (fail2ban, etc.), SSH keys prove to be a reliable and secure alternative.

How To Create SSH Keys

In this step, we will show you how to create SSH Keys. The first step to configure SSH key authentication to your server is to generate an SSH key pair on your local computer.

To do this, you can use a special utility called ssh-keygen, which is included with the standard OpenSSH suite of tools. By default, this will create a 2048 bit RSA key pair, which is fine for most uses.

Use the following command to generate an SSH key pair on your local computer.

ssh-keygen  

Generating public/private rsa key pair.  Enter file in which to save the key (/home/username/.ssh/id_rsa)

After that, the utility will prompt you to select a location for the keys that will be generated. By default, the keys will be stored in the ~/.ssh directory within your user’s home directory. The private key will be called id_rsa and the associated public key will be called id_rsa.pub.

Usually, it is best to stick with the default location at this stage. Doing so will allow your SSH client to automatically find your SSH keys when attempting to authenticate. If you would like to choose a non-standard path, type that in now, otherwise, press ENTER to accept the default.

In case you had previously generated an SSH key pair, you may see a prompt that looks like this:

/home/username/.ssh/id_rsa already exists.  Overwrite (y/n)?

But if you choose to overwrite the key on disk, you will not be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.

Created directory '/home/username/.ssh'.  Enter passphrase (empty for no passphrase):  Enter same passphrase again:

Then, you will be prompted to enter a passphrase for the key. This is an optional passphrase that can be used to encrypt the private key file on disk.

You may be wondering what advantages an SSH key provides if you still need to enter a passphrase. Some of the advantages are:

1- The private SSH key (the part that can be passphrase protected), is never exposed to the network. The passphrase is only used to decrypt the key on the local machine. This means that network-based brute forcing will not be possible against the passphrase.

2- The private key is kept within a restricted directory. The SSH client will not recognize private keys that are not kept in restricted directories. The key itself must also have restricted permissions (read and write only available for the owner). This means that other users on the system cannot snoop.

3- Any attacker hoping to crack the private SSH key passphrase must already have access to the system. This means that they will already have access to your user account or the root account. If you are in this position, the passphrase can prevent the attacker from immediately logging into your other servers. This will hopefully give you time to create and implement a new SSH key pair and remove access from the compromised key.

Since the private key is never exposed to the network and is protected through file permissions, this file should never be accessible to anyone other than you (and the root user). The passphrase serves as an additional layer of protection in case these conditions are compromised.

Note: A passphrase is an optional addition. If you enter one, you will have to provide it every time you use this key (unless you are running SSH agent software that stores the decrypted key). We recommend using a passphrase, but if you do not want to set a passphrase, you can simply press ENTER to bypass this prompt.

Your identification has been saved in /home/username/.ssh/id_rsa.  Your public key has been saved in /home/username/.ssh/id_rsa.pub.  The key fingerprint is:  a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host  The key's randomart image is:  +--[ RSA 2048]----+  |     ..o         |  |   E o= .        |  |    o. o         |  |        ..       |  |      ..S        |  |     o o.        |  |   =o.+.         |  |. =++..          |  |o=++.            |  +-----------------+  

From now on, you have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH key authentication to log in.

How To Copy a Public Key to your Server

It is time to notice that if you already have a server available and did not embed keys upon creation, you can still upload your public key and use it to authenticate to your server.

The method you use depends largely on the tools you have available and the details of your current configuration. The following methods all yield the same end result. The easiest, most automated method is first and the ones that follow each require additional manual steps if you are unable to use the preceding methods.

Copying your Public Key Using SSH-Copy-ID

Let’s see the easiest way to copy your public key to an existing server to use a utility which is called ssh-copy-id. Because of its simplicity, this method is recommended if available.

The ssh-copy-id tool is included in the OpenSSH packages in many distributions, so you may have it available on your local system. For this method to work, you must already have password-based SSH access to your server.

To use the utility, you simply need to specify the remote host that you would like to connect to and the user account that you have password SSH access to. This is the account where your public SSH key will be copied.

ssh-copy-id username@remote_host

Then, you would receive a message as below.

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.  ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

By displaying this, you can ensure that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “yes” and press ENTER to continue.

Therefore, the utility will scan your local account for the id_rsa.pub key that we created earlier. When it finds the key, it will prompt you for the password of the remote user’s account:

usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed  /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys  [email protected]'s password:

Now, type in the password and press ENTER. The utility will connect to the account on the remote host using the password you provided. It will then copy the contents of your ~/.ssh/id_rsa.pub key into a file in the remote account’s home ~/.ssh directory called authorized_keys.

Point: Your typing will not be displayed for security purposes.

Output

Number of key(s) added: 1    Now try logging into the machine, with:   "ssh '[email protected]'"  and check to make sure that only the key(s) you wanted were added.

And please be aware that your id_rsa.pub key has been uploaded to the remote account. You can continue onto the next section. At this point, your id_rsa.pub key has been uploaded to the remote account. You can continue onto the next section.

Copying your Public Key Using SSH

In case you do not have ssh-copy-id available, but you have password-based SSH access to an account on your server, you can upload your keys using a conventional SSH method.

You can do this by outputting the content of our public SSH key on our local computer and piping it through an SSH connection to the remote server. On the other side, we can make sure that the ~/.ssh directory exists under the account we are using and then output the content we piped over into a file called authorized_keys within this directory.

You may use the >> redirect symbol to append the content instead of overwriting it. This will let us add keys without destroying previously added keys.

You can see the full command below.

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"  

Then, you would receive a message as below.

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.  ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

By displaying this, you can ensure that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “yes” and press ENTER to continue.

Afterward, you will be prompted with the password of the account you are attempting to connect to:

[email protected]'s password:  

Once you entered your password, the content of your id_rsa.pub key will be copied to the end of the authorized_keys file of the remote user’s account. Continue to the next section if this was successful.

Copying your Public Key Manually

You need to do the above process manually if you do not have password-based SSH access to your server available.

The content of your id_rsa.pub file will have to be added to a file at ~/.ssh/authorized_keys on your remote machine somehow.

And to display the content of your id_rsa.pub key, type this into your local computer:

cat ~/.ssh/id_rsa.pub  

Then, you will see the key’s content

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test  

Next, you should access your remote host using whatever method you have available. Make sure the ~/.ssh directory is created, when you have access to your account on the remote server.

mkdir -p ~/.ssh  

At this point, you can create or modify the authorized_keys file within this directory. Add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if necessary, using this:

echo public_key_string >> ~/.ssh/authorized_keys  

Now, substitute the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you executed on your local system. It should start with ssh-rsa AAAA….

Move on to try to authenticate without a password, when it did work successfully.

Authenticate to your Server Using SSH Keys

You should be able to log into the remote host without the remote account’s password if you have successfully completed one of the procedures above.

The basic process is the same:

ssh username@remote_host  

You may see something as below if this is your first time connecting to this host.

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.  ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.  Are you sure you want to continue connecting (yes/no)? yes

By displaying this that your local computer does not recognize the remote host. Type “yes” and then press ENTER to continue.

But if you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be required to enter it now. Afterward, a new shell session should be spawned for you with the account on the remote system.

If successful, continue on to find out how to lock down the server.

Disabling Password Authentication on your Server

In this step, you will verify that if you were able to login to your account using SSH without a password, you have successfully configured SSH key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.

But before completing the steps in this section, make sure that you either have SSH key-based authentication configured for the root account on this server, or preferably, that you have SSH key-based authentication configured for an account on this server with sudo access. This step will lock down password-based logins, so ensuring that you have will still be able to get administrative access is essential.

And log into your remote server with SSH keys, either as root or with an account with sudo privileges. Open the SSH daemon’s configuration file, when you see the truthness of the above conditions.

sudo nano /etc/ssh/sshd_config  

Inside the file, search for a directive called PasswordAuthentication. This may be commented out. Uncomment the line and set the value to “no”. This will disable your ability to log in through SSH using account passwords:

PasswordAuthentication no  

You can save and close the file now. To actually implement the changes we just made, you must restart the service.

On Ubuntu or Debian machines, you can issue this command:

sudo service ssh restart  

On CentOS/Fedora machines, the daemon is called sshd:

sudo service sshd restart  

When you are done with this step, you’ve successfully transitioned your SSH daemon to only respond to SSH keys.

In this article, you succeeded to finish this tutorial Configure SSH Key-Based Authentication on a Linux Server. From now on you should have SSH key-based authentication configured and running on your server, allowing you to sign in without providing an account password. From here, there are many directions you can head. In case you are interested in reading more about this subject, find our related articles on Tutorial set up SSH Keys on CentOS 8 AND How to set up SSH keys on Ubuntu 20.04.