Create and Manage SSH Keys for Third-Party Integration
Recently, GitHub made it such that standard username/password login would no longer function for remote logins. In place of that aging form of authentication is Secure Shell keys and access tokens. The SSH key authentication makes it possible for users to clone and work with private repositories (at least those they have access to).
And GitHub isn’t the only service to require SSH key authentication. You might have Linux servers (either in your on-premise data center or from a cloud-hosted service) and the admin has turned off password authentication.
No matter the service, you’re going to need to understand and be able to work with SSH key authentication. I believe it will soon be the case that most services will migrate away from traditional password authentication. That being the case, you won’t have a choice but to work with the likes of SSH keys.
But how?
Although most Linux users are well-versed in the ways of SSH keys, not everyone is. To that end, I want to introduce you to the process of creating and managing SSH keys, so you can be ready to use them for third-party integration.
What Is SSH Key Authentication?
Before we get into the how let’s explain what we’re talking about first. SSH key authentication is a more secure way of authenticating a user to an account. Instead of it employing a username and password, it associates a key pair with a user. That key pair includes a private (id_rsa) and a public key (id_rsa.pub).
The private key remains on a user’s local storage (usually in the ~/.ssh directory) and is not shared with anyone. The public key, however, is shared out to other users, services, and servers.
When a user attempts to log in with an SSH key, the public and private keys are compared. If those keys match, the user is allowed access to the server.
One of the most important issues with this type of authentication is that users never share their private keys. Anyone with that private key could gain access to the account that includes the public key. This is one of the reasons why the id_rsa key has read/write access only for the owner.
With that said, let’s get our fingers dirty with SSH keys.
How to Generate SSH keys
First and foremost, I work with Linux. It’s my primary operating system for everyday usage. I also work with macOS. The good news is that working with SSH is very similar on both systems, as well as Windows. The commands you’ll see below are identical on Linux, macOS, and Windows. And, even better, the SSH client is installed (out of the box) on all three platforms.
So there should be nothing to install.
The first thing you must do is generate your SSH keypair. To do that, log into your machine, open a terminal window, and issue the command:
ssh-keygen
By default, SSH will use RSA as the type of key. If you have a reason to go with one of the other options (dsa, ecdsa, ecdsa-sk, ed25519, or ed25519-sk), you could use the -t option like so:
ssh-keygen -t TYPE
Where TYPE is the type of key to be generated.
During the key creation, you’ll be prompted to type and verify a passphrase for the key. Do not just hit enter for an empty passphrase. Make this password challenging. Even though SSH key pairs are more secure than traditional authentication methods, if you opt to shun a passphrase for the key pair, should anyone snag your private key, they won’t have any trouble accessing the account associated with the key pair.
You might have a reason to generate multiple SSH key pairs. Why? You might want to use a different key pair for different services (such as one for GitHub and one for your Linux data center servers). To do that, you’d just need to give the newly-generated key pair a different name during the creation process (Figure 1).
-
Figure 1: Giving the new SHH key pair a specific name to be used for GitHub.
With your key pair created, let’s now look at how you can manage it.
How to Use Your SSH Key Pair
The first thing I’ll show you is how to view your public key. This is quite simple. On Linux or macOS, you would simply issue the command:
cat ~/.ssh/id_rsa.pub
This will display a long string of characters, starting with ssh-rsa and ending with USER@HOSTNAME (where USER is your username and HOSTNAME is the hostname of the computer).
You could copy that key and then paste it where ever it needs to be. For example, for GitHub you do the following:
- Log into your GitHub account.
- Click on your profile image in the upper-right corner.
- From the drop-down, select Settings.
- In the left navigation, click SSH and GPG keys.
- In the resulting window (Figure 2), click New SSH key.
-
Figure 2: Adding an SSH key to your GitHub account is simple.
Then, give the key a name and paste the contents of id_rsa.pub in the Key section (Figure 3).
-
Figure 3: Paste the contents of your newly-generated SSH key here.
And then you add the SSH key.
That’s all there is to adding an SSH key to GitHub. At this point, you should now be able to more easily interact with the service. Other services handle this process in a similar fashion, so make sure to find out how to use SSH keys with other cloud- or server-based accounts you use.
But what about copying an SSH public key to one of your many Linux servers? This is even easier. Log in to the computer that houses the SHH keypair, open a terminal, and issue the command:
ssh-copy-id USER@SERVER
Where USER is the remote username and SERVER is either the IP address or domain of the remote server.
Once you’ve copied the public key to the remote server, you can then log in with the command:
ssh USER@SERVER
Where USER is the remote username and SERVER is either the IP address or domain of the remote server.
You will be prompted for the SSH key pair passphrase (not the user password). Upon successful login, you’ll be allowed access to the server. What is interesting, however, is that (until said time as your local keychain drops the cached password), you shouldn’t have to enter the SSH passphrase the next time you log in. This will, of course, depend on the local operating system and how it’s configured to cache passwords. Just don’t be surprised if, the next time you attempt to SSH into the remote machine, you aren’t asked for the passphrase.
That leads us to a very important issue. When you’ve set up SSH key authentication, you mustn’t leave your local machine unattended. Consider what I just mentioned above. With the SSH key passphrase cached, anyone could issue the SSH command to log into the remote server and gain access, without having to worry about a password.
Because of this, you should always lock your desktop when you step away from your desk. Some desktop operating systems will flush that particular cache, upon closing a terminal window or logging out. So make sure to test this before making any assumptions.
Conclusion
And that’s how you create and manage your SSH keys for third-party usage. It’s not challenging, but it might be a new skill you require, to successfully authenticate with any number of services. It won’t be long before most third-party services require the use of SSH key authentication (or something similar), so it’s best to get ahead of the game.