Join Scott Simpson for an in-depth discussion in this video SSH: Managing and distributing keys, part of Linux Tips Weekly.
- [Instructor] The SSH protocol lets us connect securely to a remote system. SSH uses the user name and password for an account on a remote server to grant access to the user connecting remotely. This can be convenient, but passwords can be guessed or stolen through a variety of means. In order to offer more security when connecting, instead of relying on passwords we can use cryptographic keys or more precisely a key pair. A key pair is made up of two files, a private key that a user keeps and a public key that's stored on a server that they need to have access to.
When the user connects, the server and client exchange key information to determine if the user is allowed to log on. We can use an existing key pair or generate a key pair to give a user who needs secure access. Generally it's the best practice to have a separate key pair for each system you need to access, but that isn't always practical and it is okay in some circumstances to use one key for more than one system. Depending on the requirements of your environment, your administrator should decide what an appropriate balance is. We won't get into that here though. Let's take a look at generating a key pair to use for remote SSH access.
The tool we use is called SSH keygen. It offers a lot of different options for changing the encryption algorithm, how many bits are used and so on. The man pages go over those in detail. Without any option specified, the tool uses the RSA algorithm and 2048 bits, which is fine for normal uses. I'll run the command here, ssh-keygen, and then I'll go through the prompts. First, I'm asked where I want to save the key. The tool suggests the hidden .ssh folder in my home folder, under a name id_RSA.
This is the default but you can set any name you like. The SSH tool knows to look for a key here, so keeping it named like this can save a little bit of time. If you're using many keys, it can be helpful to name them descriptively, if you plan to use the key with a specific username or a specific server. I'll accept this name and then I'm asked to enter a passphrase. It can be a good idea to set a passphrase on a key. You'll need to type it in whenever the key is used or you'll need to store in your key chain. Using a passphrase can be a little annoying, but it helps to further secure a key.
Even if someone copies your private key file, they'll need the password in order to use it. So I'll put a password here, and I'll confirm it. And then the key pair is generated. The private key is saved in the file here with no extension and the public key is saved in the file ending in .pub and we have a fingerprint and a random art image which can be used to visually verify a key if needed. Once a key pair is generated, we need to send the public key to the server. We can distribute this public key widely without much concern for security because in order to use it, we have to employ our private key as well.
It's common to send public keys to people you're collaborating with and to paste them into systems like Github, where you want to be able to have secured access using your private key. You can email or send the .pub file or you can copy and paste the text of the public key. The private key, however, you want to keep secret. Let's take a look at both of these files so you can see what they look like. I'll list them first, and you can see that the private key has pretty restrictive permissions. Only my user can read and write it, and nobody else can. That's important because it's supposed to be private just to me.
Let's take a look at the public key first. It's one long line and it starts out with a protocol, SSH-RSA, and then a string that represents the actual public key. And at the end, there's a user @ host name where the key was generated. You can set this to something else with the -C option, which means comment. Github recommends that you set this to your email address for example, so if someone asks for your public key, you can just copy and paste this whole chunk and send it to them. Now, let's look at the private key. Normally you wouldn't want to show strangers on the internet your private key, but we just generated this one and I'll be deleting it later, so it doesn't really matter.
Unlike the public key, this one is a formatted block bounded by notations about it being a private key. This is visually distinct from the public key, and you always want to double check what you're copy and pasting when you work with keys. Okay, I'll get the text of the public key again here. And I'll copy that, then I'll connect to another SSH server here on my network. This server is using passwords right now, so let's set it up to accept keys using this key that we just generated.
I'll log in and then over in the .ssh folder for my user, I'll create a file called authorized keys. I'll paste my public key in here with Control-Shift-V and then I'll save. Now I'll go over to the SSH configuration file at etc/ssh/sshd_config and I'll look for the directive PasswordAuthentication, I'll uncomment it and I'll set it to no.
And I'll save the file. Then I'll restart my SSH daemon on this remote machine with systemctl_restart_sshd. Now I'll disconnect from the session. Here on GNOME, I can add my key to my key chain so I don't have to type the password every time I use it. To do that write ssh-add and I'm prompted for the password for my key. This will store it in my key ring so I don't have to type it every time. If you're using a different system, when you try to use the key, you'll be prompted for the password.
Now, if I try to connect to my SSH server, I won't be allowed to. I need to specify -I and the path to my private key file in order to connect. And now I'm connected. I can take a look at the log on the remote machine too to see how I'm connecting in with tail /var/log/auth.log. Here I can see the fingerprint of the key pair that I was using. I'll exit out of here again. If you need to find the fingerprint of a key, you can use ssh-keygen with the -lf options and the path to the key.
You want to make sure to safeguard and back up your private key, and it's a good idea to back up the public key too just in case. Sometimes people store private keys on hardware like a YubiKey in order to improve security. They can also be stored on regular removable media or even on the system's built-in storage. It's all a matter of how much security you're willing to trade for convenience.
Note: Because this is an ongoing series, there is no certificate of completion available for this course.