This post originally appeared on the Packet Pushers’ Ignition site on February 18, 2020.
The more pedantic in the tech community argue about the merits of public-private key authentication vs. simple password authentication when logging into an SSH host. I have no strong opinion regarding your security posture when using one vs. the other. The presence of this how-to should not imply that key pair authentication is decidedly more secure than a password. The truth of the matter is, “It depends.™”
What follows is a quick reference for those interested in using a public-private key pair to authenticate to a remote SSH host.
Create The Key Pair
Create a public-private key pair from a host with the ssh-keygen tool. You could do it on a Linux box. MacOS also has ssh-keygen available in a terminal session. Microsoft offers instructions for Windows users here.
We’ll proceed using ssh-keygen. Execute the command that follows as a bare minimum–you might want to make larger keys depending on your personal level of paranoia by adding -b <bits>.
1 |
ssh-keygen -t rsa |
Plumb the depths of the ssh-keygen command and its sundry parameters as implemented on Ubuntu 18.04 here. I have not memorized all of the parameters (and hope never to do so).
You can make many key pairs if you like. However, be careful not to overwrite your existing key pair if the one you already have is important to you.
Passphrase The Private Key
Give your private key a passphrase when prompted. If you don’t define a passphrase, anyone who gets a copy of your private key–it’s just a file, after all–will be able to use it to authenticate against any server which has your public key. If you do assign a passphrase to the private key, you’ll be prompted for the passphrase when using the private key to authenticate to a server.
That might seem like too much trouble. Perhaps you want to use a key pair to avoid the tedious step of typing in a password to authenticate. For home lab environments, I suppose that’s just fine. But for any sort of environment where the remote host should be properly protected from nefarious ne’er-do-wells, use a passphrase.
Your Keys Are Just Text Files
When ssh-keygen completes, you’ll end up with 2 files. You should be able to find them in ~/.ssh/ assuming a *nix sort of box such as those running a Linux distro or MacOS.
- Private key–id_rsa. Protect this file. Don’t let anyone get a hold of it. Treat it as you would a password. Don’t leave it lying around in an unsecured S3 bucket, for example.
- Public key–id_rsa.pub. This is the one you’ll copy to remote hosts.
Think of these files as two friends that work together for, in our use case, SSH authentication. These files are not tied to a specific username or host. You can use them anywhere you like, as long as you’ve put them in the right places.
Distribute Your Keys
Putting your keys in the right places means two sorts of places.
- Hosts. The hosts you want to authenticate to get a copy of your public key.
- Clients. The SSH client aka terminal software needs access to your private key.
On the remote host, append the text of the public key file to ~/.ssh/authorized_keys. The ~ represents the home directory of the Linux user account you want to authenticate as using the keypair. If there is no ~/.ssh/authorized_keys file, create one and copy the contents of the public key into it.
In your SSH client, configure the session to authenticate to the Ubuntu box with your username and the private key. That will consist of configuring a specific terminal session to use the private key file, so you’re likely storing it locally somewhere.
For instance, if your client is running on your laptop, you’ll have a copy of that private key on your laptop as well. The most common place to store your private key is in your home directory in the .ssh folder, but it doesn’t have to be there. Maybe you’d rather store it on an encrypted thumb drive you keep in your pocket when you’re away from your desk.
The steps for this will vary from client to client. Here’s a screenshot from Emtec’s ZOC to help you get the idea.
Using Your Keys
Now that your remote host and SSH client are configured with the public and private keys respectively, you should be set to login. If you were using a cached password previously in your SSH client profile, you will be able to leave that field blank now. The username will remain the same.
Note that the public-private key pair you’ve created is used only for authentication. The ongoing encryption between your SSH client and the remote host post-authentication is negotiated separately and does not use your authentication key pair.
SSH Key Pair Authentication For Cisco IOS Devices
I published a video on the Packet Pushers YouTube channel demonstrating how to set up SSH keypair authentication for Cisco IOS devices if you want to see more about this topic.
For even more on private and public keys and encryption, check out this 6-video series with Ed Harmoush on using OpenSSL.