SSH key agents - security *and* convenience

Have you seen those commercials where folks imagine what it would be like to use nuts or bolts instead of nuts and bolts? I too prefer and most of the time. All too often in the world of computer security, we have to make a trade-off between security and usability, a direct analogy to the "or" case. We can make it secure but hard to use. Or we can make it easy to use, but then it's too weak. So typically a compromise is selected somewhere in the middle, usually towards the security end of the scale, of course. So this ends up being "secure or usable".

A great example that everyone can understand is password policies and their required complexity.
Suppose we start at one end of the spectrum and have no policy. Most people will then use something very easy to remember (e.g. 1234 or blank). Unfortunately, that has almost no security strength. Anyone could crack that with a near-trivial effort. But it sure is easy to use! Going to the other extreme, we could require the password to be a 20 or 30 character random string. That's extremely strong, but most people could never remember it or type it correctly, especially on virtual keyboards where it's usually a pain to get to all the special characters. Good luck getting anyone to use your service like that. So we end up compromising in the middle. The password can be 8-12 characters, two upper-case, two lower-case, two number, two specials, etc. Now people can make up something memorable, but it's still strong enough to resist a quick break-in. That's not as strong as it could be and not as usable as it could be. Those are two competing factors in this case. I'm not sure we'll ever be satisfied with it.

Remember the security triangle with the three sides of confidentiality, integrity and availability?
Part of availability is authorized users being able to access resources when they need to.
If you choose a password complexity that creates a severe enough usability problem, then users will have difficulty on a daily basis getting into the systems they need to. Is this really any different than some hacker making the system unavailable via denial-of-service attacks? Not from the user's perspective it isn't. They can't get into the <expletive> system again. And then a slow burn of anger against IT and management begins. Let's not go there.

But every so often, we find a use-case where we can have our cake and eat it too. The Secure Shell (SSH) protocol supports a variety of authentication options. It supports and defaults to password authentication where you end up fighting all the stuff I just mentioned. But it also supports public-key authentication. We generate a public/private key pair, install the public key on a remote system that we have access to and then we can authenticate without using our remote account password. Awesome. But wait... you have to give your local ssh commands access to your private key and that is protected by a pass-phrase. A pass-phrase can be anything and, so far, I have never encountered any means of enforcing a policy on that. But suppose we follow good password/pass-phrase practice and give it a strong one. Aren't we back to square one now?

Not really. There are two mitigating factors that help in this case.

First, as I mentioned, there is no complexity policy associated with the private key pass-phrase. Why not? Because by it's very design and definition, the private key is private. It's for your eyes only. You don't get one from your system administrator or download it from the "cloud". You create it on a local system and protect it from access by others like any other file on the system. Yes, your local admin could lay hands on the file, but you have to trust him/her anyway. And the pass-phrase should prevent them from actually using it. The private key never actually leaves the local system. It is never transmitted over the network in the clear or otherwise. It gets used locally to encrypt portions of the SSH session negotiation so the other end can verify things using your public key, but the key itself stays put. So unless someone can hack your local system, they can't even try to use the file. Contrast this with passwords which are a direct input of the remote authentication process, thus allowing a hacker to try different values in an attempt to get in. They don't need your "help" with passwords.

So although you're on your own with regards to the complexity of the pass-phrase, the risk of anyone being able to make use of the private key is significantly smaller than passwords. And it's called a pass-phrase rather than a password because it can be literally any string. For example, you could type a short sentence that involves some upper-case letters, numbers and special characters that creates length, but is very easy to remember. For example, "My lucky number is 314159!". Sure it uses some English dictionary words, but look at the length. 26 characters long without even trying hard and trivial to remember and type easily. Try that with a password when spaces are not allowed and you start trying to come up with clever mnemonics and such.

The second factor is a very handy program associated with SSH called the "key agent".
Once invoked, the key agent process runs in the background as your user. It's not a daemon or system-level service. This helps prevent other users from abusing your agent (insider threat). So what does it do? After logging into your local system and invoking an SSH command (ssh, sftp, scp) for the first time and giving your pass-phrase to unlock the private key, the agent caches the fact that you authorized private key access. Every successive time you need it for another ssh command, the agent is contacted first and if you have already unlocked the private key, it tells the command that you did so and it can proceed without you re-entering the pass-phrase every time. Nice!

In my work environment, I typically stay logged into my workstation 24/7 and just lock the screen-saver. I only log in to the desktop from scratch when there's been a power outage or I have to update the kernel, etc. Under good conditions, I may be logged in to a single session for months at a time. And the first time in, I gave my private key pass-phrase and started the key agent. So every single ssh command after that just happens smoothly without interruptions. This is a tremendous efficiency boost to my workflow because I use ssh command several times a day, every single day. So I now have the security of SSH with public-key authentication *AND* the convenience of not typing the pass-phrase 10 times a day. WIN. :)

It gets better. Suppose you have to do a multi-hop SSH session through an intermediate host system. For example, your local system is A and you want to get to system C. But there is no direct path. You have to go through system B. Without a key-agent, you would ssh from A to B (and give the phrase). Then ssh from B to C (and give the phrase again). By learning two things, we can make this just as simple and smooth as our simple, single-system scenario. First, the ssh command has an option -t to force a pseudo-tty allocation. Normally, ssh expects to connect to an interactive login shell on the other side which has a tty. By using -t, we can just skip on through the middle system(s) without stopping there first and running the second ssh command manually.

ssh -t user@systemB ssh user@systemC

That takes care of the annoying "stop" at system B, but you'll still have to give your pass-phrase twice. Why? Once for system A and then again for the second session from system B. However, you can configure the local sshd to allow agent forwarding (see AllowAgentForwarding keyword in /etc/ssh/sshd_config). This tells your local SSH service that it's ok to send the cached authentication ahead and use it again on system B. Once you do that, the command above just drops you out directly on system C with no prompting.

For further convenience, there is a great package called keychain that makes using the key agent very easy. The first time you run it, it will create some tiny (~2 line) shell script that are designed to be sourced from your .bashrc when you start a new shell. If it discovers that ssh-agent is not yet running, it starts it and prompts for your private key pass-phrase to cache the authorization. If the agent is running and you've already authorized, then it just sets a couple of environment variables so the ssh programs can find the proper agent. Then you don't have to do anything no matter how many different shells you open within your one desktop session. After the first pass-phrase entry, every other ssh command just works.

This post maps to CompTIA SY0-301 exam objectives 1.4, 2.8 and 5.3.