Setting Up Passwordless SSH

Content:

If you’re a regular SSH user, having to repeatedly enter passwords can become rather tedious. Removing the password is not a valid solution – doing so leaves the target system wide open to hackers.

Fortunately, it’s possible to authenticate an SSH connection using public key authentication. A private key is generated, and stored on the connecting machine. The corresponding public key is saved on the remote machine. As long as the remote machine has the right public key, the connection will be made without requiring a password.

In this guide, we go through how to set up your private/public key pair.

Generating the Key Pair

There are a few ways you can generate the key pair. The method we’ll be using is one of the simplest, using a tool called ssh-keygen.

ssh-keygen

On running this command, you’ll be asked a few questions. These can be left blank/default, though you can add a passphrase if you wish to secure the key pair.

If you do this, you’ll occasionally be asked to enter this passphrase when connecting over SSH. On the flip side, not using a passphrase leaves your private key vulnerable should the machine be compromised.

Weigh up the pros and cons of using a passphrase for your specific use-case.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:eXcATvBfm/UEI/a1NNn2XGANZzfHMNcgeFuQmE5N4HI user@machine
The key's randomart image is:
+---[RSA 3072]----+
|        ..+B*oX@@|
|         ==o+=oX&|
|        .oE..oo+=|
|         +...o =+|
|        S . o + .|
|         . . .   |
|                 |
|                 |
|                 |
+----[SHA256]-----+

At the end of the output, you’ll see the key fingerprint and corresponding randomart. This data can be used to check the validity of the public key later on.

You can access this data at any time using

ssh-keygen -lv

and selecting the key you want to check.

To access the generated public key, open .pub file specified in the ssh-keygen output.

cat /home/user/.ssh/id_rsa.pub

You should see a long string, followed by your username and machine hostname.

ssh-rsa AAAAB3NzaC1yc2EAA... user@machine

Key generation is now complete.

Propagating the Key

Once the key pair has been generated, the public key needs to be propagated to machines you want to access.

The easiest way to do this is by using the ssh-copy-id tool. Simply enter the username and hostname of the remote machine.

ssh-copy-id remote-user@remote-machine

You’ll then be prompted for the password of the remote user, as you would be when connecting using ssh.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_rsa.pub"
/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
remote-user@remote-machine's password:

Once the password is entered, the public key will be copied. You should see an output similar to the below.

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'remote-user@remote-machine'"
and check to make sure that only the key(s) you wanted were added.

To test the key, connect to the remote machine using ssh.

ssh 'remote-user@remote-machine'

You should be able to connect, without the need to enter the password for the remote user. If you added a passphrase to your key pair, you may be prompted to enter this passphrase. If so, disconnect and reconnect via ssh, and you shouldn’t be prompted for the passphrase on the second connection.

Revoking a Public Key

In the event that a key pair becomes compromised, you’ll need to generate a brand new key pair using the process outlined above.

While this is enough to generate a new key pair, the old public key will still remain on the remote system. If the private key has been compromised, another machine would be able to use this to connect to the remote system.

To revoke the public key, first log in to the remote system.

From there, check the contents of the authorised key list.

cat .ssh/authorized_keys

You’ll see all of the authorised keys listed.

ssh-rsa AAAAB3NzaC1yc2EAA... user@machine
ssh-rsa AAsfeUtRgs12W21PA... user@machine2
ssh-rsa A9RAB3UlA81y58EOM... user@machine3

Here, the user@machine combination refers to the username and localhost of the machine that is authorised to connect using this public key.

Identify the key that needs to be removed, and delete the appropriate line from this file. If you’re unsure which key to remove, it may be easier to revoke all keys assigned to the relevant user/machine, and propagating the new key afterwards.

Updating the Passphrase

From time to time, you might want to update the passphrase used to secure your private key. Alternatively, you might decide to add/remove the passphrase from your private key.

You can do this using ssh-keygen, with the -p parameter.

ssh-keygen -p

You’ll be asked to specify the path to the key file to apply the change to, followed by entering the new passphrase.

Enter file in which the key is (/home/user/.ssh/id_rsa): 
Key has comment 'user@machine'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

Disabling Password Login

While a password is no longer required to log in, it’s still possible to do so from a machine that doesn’t have a key pair set up.

As an additional step, you might wish to disable password-based logins entirely.

Log in to the remote system, and open the sshd_config file.

nano /etc/ssh/sshd_config

Search for the PasswordAuthentication option, and set the value to no.

PasswordAuthentication no

Save the file, and restart sshd. The command below is suitable for systems using the SystemD init system.

systemctl restart sshd

Be aware that this will prevent ssh-copy-id from propagating new public keys in the future. Temporarily enabling password-based login is a potential workaround in this situation.