How to Set Up An SSH Key Agent

Last week I showed you how to set up cryptographic authentication for SSH. We got as far as the more secure part. In an analysis of a multi-year collection of several million SSH break-in attempts I didn’t see one that tried guessing cryptographic keys.

Willie Sutton supposedly said that he robbed banks because that’s where the money was. Invest effort wisely. Humans can write programs that efficiently guess passwords that other humans select and can remember.

That’s where the money is, guessing human-chosen passwords. Not in guessing 521-bit elliptic curve keys, where there are 2⁵²¹ ≈ 7×10¹⁵⁶ possible keys.

I feel pretty comfortable with that large of a key space to hide in.

Automating Authentication

Let’s say that you took Learning Tree’s Linux server administration course and learned how to administer an enterprise-class Linux server. But you have a few of them, or a few dozen, or a few hundred, or even more. You need to automate tests and updates, but you want to keep this secure. Your SSH keys are a great start.

An SSH Key Agent

You need an SSH key agent, a process that is associated with your login session and which carefully handles your SSH private keys. The core of this is the program ssh-agent.

The agent is started first, then your login session and everything started from within that session is associated with this persistent agent process. You use ssh-add to allow the running ssh-agent process to access your private keys. It will ask you for your SSH key pass phrase.

You type that passphrase once, and your ssh-agent process now handles your SSH private keys for as long as it runs.

What Does The Agent Have? Three Possibilities

You can ask for a list of currently known keys:

$ ssh-add -l

There are three possible outcomes.

First:
Error connecting to agent (or similar)

Oops, no agent is running! I’ll show you how to get one started in a moment.

But second, you might see:
The agent has no identities.

OK, an agent is running, but you haven’t given it access to your public keys yet. Run the command ssh-add with no options, it will prompt you for your key pass phrase, and now it should have keys and we will see…

The third possibility is a list of key fingerprints:

4096 cd:9e:8b:87:03:cb:7b:dd:03:a1:24:b1:3a:7b:37:fc /home/cromwell/.ssh/id_rsa (RSA)
521 96:00:57:08:44:d3:a4:12:1a:04:57:95:30:9a:53:ab /home/cromwell/.ssh/id_ecdsa (ECDSA)
256 56:f1:b2:72:f0:68:e9:77:29:88:e8:6f:fb:54:7d:22 /home/cromwell/.ssh/id_ed25519 (ED25519)

This is what we want to see!

Getting a Key Agent Started

This might be done by your login process, especially if you use a graphical desktop like Gnome or KDE. In this case you see the message about the agent running but having no identities.

If one isn’t running, and you get the error message about a failure to talk to the agent, then we need to get one started when you log in.

I have found ways to modify the display manager to start an SSH agent, but I have concluded that there is a better approach.

Use the Keychain

Add the Keychain package.

It’s easy to set it up — basically get the package installed, use it once, and then every time you log in it will start ssh-agent if needed and prompt you for the pass phrase to pass to ssh-add.

Depending on what all you install, it may pop up a graphical window and ask you for the pass phrase. Otherwise, the initial terminal window(s) will will ask you.

 * keychain 2.7.1 ~ http://www.funtoo.org
 * Starting ssh-agent...
 * Starting gpg-agent...
 * Adding  4 ssh key(s): /home/cromwell/.ssh/id_rsa
        /home/cromwell/.ssh/id_dsa
        /home/cromwell/.ssh/id_ecdsa
        /home/cromwell/.ssh/id_ed25519
Enter passphrase for /home/cromwell/.ssh/id_rsa:
 * Identities added: /home/cromwell/.ssh/id_rsa
        /home/cromwell/.ssh/id_dsa
        /home/cromwell/.ssh/id_ecdsa
        /home/cromwell/.ssh/id_ed25519 

GNOME Gotchas

As I explained earlier, I don’t care much for the Gnome desktop environment. I knew that it was an unreasonable load on system compute resources. Now I have just recently discovered that it imposes security limitations.

The Gnome desktop’s keyring program can’t handle ECDSA or Ed25519 keys! This is a problem known since early 2011 for ECDSA and since early 2014 for Ed25519!

I had to figure this out for a client locked into a stock Red Hat desktop environments. Since I use the KDE Desktop Environment personally, I hadn’t tripped over this limitation.

To me, this is yet another reason to avoid Gnome. If you must use it, disable its keyring (suggestions here) and use Keychain.

Red Hat Enterprise Linux Gotchas

And in the process of figuring out that last part, I also discovered that the version of ssh-keygen on RHEL 7.0 can’t do Ed25519 key pairs! (It looks like this is fixed by RHEL 7.2)

So…

Be careful out there! Use all you can of the latest security technology to stay safe!