Knowledge Base
MilesWeb / How-Tos, Web Hosting FAQ

How to Set Up SSH Keys on Ubuntu 18.04

Approx. read time : 8 min

How to Set Up SSH Keys on Ubuntu 18.04

Introduction

SSH (secure shell) is the encrypted protocol used to administer and interact with servers. You will spend maximum time in the terminal session connected to your server through SSH when working with an Ubuntu server.

In this guide, you will learn how to set up SSH keys for Ubuntu 18.04 installation. SSH keys deliver an easy and secure way of logging into your server also is recommended for all users.

STEP 1 – Create the RSA Key Pair

Create a key pair on the client machine (generally your computer):

ssh-keygen

ssh-keygen will create a 2048-bit RSA key pair by default, which is safe for most used cases (you can pass in the -b 4096 flag to create a higher 4096-bit key optionally).

After executing the command, you will see the following output:

Output
Generating public/private rsa key pair.
Enter file in which to save the key (/your_home/.ssh/id_rsa):

Hit Enter to save the key pair into the .ssh/ subdirectory in your root (home) directory or define an alternate path.

You may see the following prompt if you had generated an SSH key pair previously:

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

If you want to overwrite the key on disk, you will be unable to verify using the previous key anymore. Be very careful when choosing yes because this is a deadly process that cannot be reversed.

You should then see the following prompt:

Output
Enter passphrase (empty for no passphrase):

Here you optionally can enter a secure passphrase, highly recommended. A passphrase adds an extra security level to prevent unauthorised users from logging in.

You will see the following output:

Output
Your identification has been saved in /your_home/.ssh/id_rsa.
Your public key has been saved in /your_home/.ssh/id_rsa.pub.
The key fingerprint is:
a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 [email protected]_host
The key’s randomart image is:
+–[ RSA 2048]—-+
| ..o |
| E o= . |
| o. o |
| .. |
| ..S |
| o o. |
| =o.+. |
|. =++.. |
|o=++. |
+—————–+

You currently have a public and private key that you can use to authenticate. Next, put the public key on your server so that you’ll be able to use SSH-key-based authentication to log in.

STEP 2 – Copy the Public Key to Ubuntu Server

The fastest way to copy your public key to the Ubuntu host is to use a utility named ssh-copy-id. This method is highly recommended due to its simplicity. If you don’t have ssh-copy-id available for you on your client machine, you can use one of the two alternative methods given in this section (manually copying the key or copying through password-based SSH).

Copying Public Key Using ssh-copy-id

The ssh-copy-id tool is built-in by default in multiple operating systems so you can access it on your local system. For this method to work, you need password-based SSH access to your server.

You simply need to define the remote host that you wish to connect as well as password-based SSH user account access to use the utility. Your public SSH key will be copied to this account.

The syntax is:

ssh-copy-id [email protected]_host

 

You will see the following message:

Output
The authenticity of host ‘203.0.113.1 (203.0.113.1)‘ 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

 

After that, the utility will scan your local account for the id_rsa.pub key that we created previously. It will prompt you for the password of the remote user’s account after it finds the key.

Output
/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
username@203.0.113.1‘s password:

Type the password (password will not be displayed for security purposes) and hit ENTER. The utility will connect to the account on the remote host using the password you entered. Then it will copy the details of your ~/.ssh/id_rsa.pub key into a file in the remote account’s home ~/.ssh directory named authorized_keys.

You can see the following output:

Output
Number of key(s) added: 1
Now try logging into the machine, with: “ssh ‘username@203.0.113.1‘” and check to make sure that only the key(s) you wanted were added.

 

At the same time, your id_rsa.pub key has been uploaded to the remote account. You can continue with STEP 3.

Copying Public Key Using SSH

If you don’t have ssh-copy-id ready, but you have password-based SSH access to an account on your server, you can upload your keys using a standard SSH method.

We can do this through the cat command to read the contents of the public SSH key on our local machine and channeling that by using an SSH connection to the remote server.

As well as, we can ensure that the ~/.ssh directory exists and needs the correct permissions under the account we’re using.

We can then output the content we channeled, ended into a file named authorized_keys within this directory. We’ll use the >> redirect symbol to affix the content rather overwriting it. This will allow us to add keys without killing previously added keys.

The command looks like this:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host “mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys”

 

You may get the following message:

Output
The authenticity of host ‘203.0.113.1 (203.0.113.1)’ 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

This means that your local computer does not identify the remote host. This can happen the first time you connect to a new host. Type “yes” and press ENTER to continue.

Then, you will be prompted to enter the remote user account password:

Output
username@203.0.113.1‘s password:

 

After entering your password, the details of your id_rsa.pub key will be copied at the end of the authorized_keys file of the remote user’s account. If it was successful, continue with STEP 3.

Copying Public Key Manually

You have to finish the above process manually, if you do not have password-based SSH access to your server accessible.

We will manually affix the content of your id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote computer.

To show the content of your id_rsa.pub key, type the following into your local machine:

cat ~/.ssh/id_rsa.pub

 

You will see the key’s content, It looks something like this:

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== [email protected]

 

Access your remote host using that method you have available.

Once you gain access to your account on the remote server, ensure the ~/.ssh directory exists. The following command will create the directory if required, or do nothing if it already exists:

mkdir -p ~/.ssh

 

Now, you can create or edit the authorized_keys file within this directory. You also can add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if required through this command:

echo public_key_string >> ~/.ssh/authorized_keys

In the above command, replace the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you performed on your local machine. It should start with ssh-rsa ABCD….

Finally, we will make sure that the ~/.ssh directory and authorized_keys file have the relevant permissions set:

chmod -R go= ~/.ssh

 

This repeatedly removes all “group” and “other” permissions for the ~/.ssh/ directory.

If you are using the root account to set up keys for a user account, it’s also necessary that the ~/.ssh directory refers to the user and not to root:

chown -R alex:alex ~/.ssh

In this guide, our user is named alex but you have to replace the relevant username into the above command.

STEP 3 – Authenticate to Ubuntu Server Using SSH Keys

If you have successfully performed one of the procedures mentioned above, you don’t require the remote account’s password to log into the remote host.

The basic process is the same:

ssh username@remote_host

 

If this is your first time connecting to this host (if you did the last process mentioned above), you may look something like this:

Output
The authenticity of host ‘203.0.113.1 (203.0.113.1)’ 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

 

This means that your local machine does not identify the remote host. Type “yes” and then press the ENTER button to continue.

If you didn’t provide a passphrase for your private key, you will be logged in instantly. If you provided a passphrase for the private key when you created the key, you will be prompted to enter it now. After validating, a new shell session will open for you with the configured account on the Ubuntu server.

Note: Your keystrokes will not display in the terminal session for security purposes.

If key-based authentication is performed successfully, continue on STEP 4 to see how to more secure your system by disabling password authentication.

STEP 4 – Disable Password Authentication on your Server

If you are able to log into your account through SSH without a password, you have successfully configured SSH-key-based authentication to your account. But, your password-based authentication mechanism is still alive, indicating that your server is still exposed to brute-force attacks.

Before executing the steps in this section, ensure that you either have SSH-key-based authentication configured for the root account or preferably, for a non-root account on this server with sudo privileges. This step will lock down password-based logins, so making sure that you will still be able to get administrative access is critical.

When you have verified that your remote account has administrative rights, log in to your remote server through SSH keys, either as root or with an account with sudo privileges. Then, open up the SSH daemon’s configuration file:

sudo nano /etc/ssh/sshd_config

 

Search for a directive named PasswordAuthentication inside the file. This might be commented out. Uncomment the line and set the value as “no”. This will disable your capability to log in through SSH using account passwords:

/etc/ssh/sshd_config

PasswordAuthentication no

Save and Close the file once you are completed by pressing CTRL + X, then enter Y to confirm saving the file and finally hit the ENTER button to exit nano. To execute these changes, we require restarting the sshd service:

sudo systemctl restart ssh

 

For safety, open up a new terminal window and check that the SSH service is working correctly before closing this session:

ssh username@remote_host

 

Once you have verified your SSH service, you can safely close all current server sessions.

The SSH daemon now only responds to SSH keys on your Ubuntu server. Password-based authentication has successfully been disabled.

Conclusion

You should now have configured SSH-key-based authentication on your server, which allows you to sign in without giving an account password.

With over 8+ years of experience in the digital marketing industry, I have achieved extensive exposure to result-oriented methodologies. And expertise in different domains like Datacentre Services, Cloud computing technology, Web hosting industry and many more.
Need help? We’re always here for you.