Ubuntu Server 18.04 – Getting started with SSH key management

How to Activate Windows Server 2019

When you connect to a host via SSH, you’ll be asked for your password, and after you authenticate you’ll be connected. Instead of using your password though, you can authenticate via Public Key Authentication instead. The benefit to this is added security, as your system password is never transmitted during the process of connecting to the server. When you create an SSH key-pair, you are generating two files, a public key and a private key. These two files are mathematically linked, so if you connect to a server that has your public key, it will know it’s you because you (and only you), have the private key that matches it. While public key cryptography as a whole is beyond the scope of this tutorial, this method is far more secure than password authentication, and I highly recommend that you use it. To get the most out of the security benefit of authentication via keys, you can actually disable password-based authentication on your server so that your SSH key is your only way in. By disabling password-based authentication and using only keys, you’re increasing your server’s security by an even larger margin. We’ll go over that later in the tutorial.

To get started, you’ll first need to generate your key. To do so, use the ssh-keygen command as your normal user account. The following screenshot shows what this process generally looks like:

Generating an SSH key-pair

First, you’ll be asked for the directory in which to save your key files, defaulting to /home/<user>/.ssh. You’ll next be asked for a passphrase, which is optional. Although it does add an additional step to authenticating via keys, I recommend that you give it a passphrase (which should be different than your system password) since it greatly enhances security. You can press Enter for the passphrase without entering one if you do not want this.

What this command does is create a directory named .ssh in your home directory, if it doesn’t already exist. Inside that directory, it will create two files, id_rsa and id_rsa.pub. The id_rsa file is your private key. It should never leave your machine, be given to another user, or be stored on any external media. If your private key leaks out, your keys can no longer be trusted. By default, the private key is owned by the user that created it, with rw permissions given only to its owner.

The public key, on the other hand, can leave your computer and doesn’t need to be secured as much. Its permissions are more lenient, being readable by everyone and writable by the owner. You can see this yourself by executing ls -l /home/<user>/.ssh:

Listing the contents of the .ssh directory, showing the permissions of the newly-created keys

The public key is the key that gets copied to other servers to facilitate you being able to log in via the key-pair. When you log in to a server that has your key, it checks that it’s a mathematical match to your private key, and then lets you log in. You’ll also be asked for your passphrase, if you chose to set one.

To actually transmit your public key to a target server, we use the ssh-copy-id command. In the following example, I’ll show a variation of the command that’s copying the key to a server named unicorn:

ssh-copy-id -i ~/.ssh/id_rsa.pub unicorn

With that command, replace unicorn with the hostname of the target server, or its IP address if you don’t have a DNS record created for it. You’ll be asked to log in via password first, and then your key will be copied over. From that point on, you’ll log in via your key, falling back to being asked for your password if, for some reason, your key relationship is broken. Here’s an example of what this process looks like:

Using the ssh-copy-id command to copy a public key to a server

So, what exactly did the ssh-copy-id command do? Where is your public key copied to, exactly? What happens with this command is that on the target server, an .ssh directory is created in your home directory if it didn’t already exist. Inside that directory, a file named authorized_keys is created if it didn’t exist. The contents of ~/.ssh/id_rsa.pub on your machine are copied into the ~/.ssh/authorized_keys file on the target server. With each additional key you add (for example, you connect to that server from multiple machines), the key is added to the end of the authorized_keys file, one per line.

Using the ssh-copy-id command is merely a matter of convenience, there’s nothing stopping you from copying the contents of your id_rsa.pub file and manually pasting it into the authorized_keys file of the target server. That method will actually work just fine as well.

When you connect to a server that you have set up a key relationship with via SSH, SSH checks the contents of the¬†~/.ssh/authorized_keys file on that server, looking for a key that matches the private key (~/.ssh/id_rsa) on your machine. If the two keys are a mathematical match, you are allowed access. If you set up a passphrase, you’ll be asked to enter it in order to open your public key.

If you decided not to create a passphrase with your key, you’re essentially setting up password-less authentication, meaning you won’t be asked to enter anything when authenticating. Having a key relationship with your server is certainly more secure than authenticating to SSH via a password, but it’s even more secure with a passphrase and creating one is definitely recommended. Thankfully, using a passphrase doesn’t have to be inconvenient. With an SSH agent, you can actually cache your passphrase the first time you use it, so you won’t be asked for it with every connection.

To benefit from this, your SSH agent must be running. To start it, enter the¬†following command as your normal user account on the machine you’re starting your connections from (that is, your workstation):

eval $(ssh-agent) 

This command will start an SSH agent, that will continue to run in the background of your shell. Then, you can unlock your key for your agent to use:

ssh-add ~/.ssh/id_rsa 

At this point, you’ll be asked for your passphrase. As long as you enter it properly, your key will remain open and you won’t need to enter it again for future connections, until you close that shell or log out. This way, you can benefit from the added security of having a passphrase, without the inconvenience of entering your passphrase over and over.

There will, at some point, be a situation where you’ll want to change your SSH passphrase. To do that, you can execute the following command, which will allow you to add a passphrase if you don’t have one already, or change an existing passphrase:

ssh-keygen -p 

Once you enter the command, press Enter to accept the default file (id_rsa). Then, you’ll be asked for your current passphrase (leave it blank if you don’t have one yet) followed by your new passphrase twice. The process looks like this:

Changing an SSH passphrase

These concepts may take a bit of practice if you’ve never used SSH before. The best way to practice is to set up multiple Ubuntu Server installations (perhaps several virtual machines), and practice using SSH to connect to them, as well as deploying your key to each machine via the ssh-copy-id command. It’s actually quite easy once you get the hang of it.

Comments are closed.