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 2521 ≈ 7×10156 possible keys.
I feel pretty comfortable with that large of a key space to hide in.
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.
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.
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!
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.
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
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.
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!