It used to be that only the paranoid among us focused on strict security practices, yet these days, it seems like people are stepping up their games with respect to encryption, password policy and how they approach their computers in general. Although I always have considered myself more inside that paranoid camp than outside of it, I even have found myself stepping up my game lately. Security is often at odds with convenience, yet whenever I need a good example of better security practices that are more convenient than the alternative, I turn to SSH keys.

With SSH keys, you generate a private and public key pair with the ssh-keygen command and distribute the public key to servers to which you want to connect. SSH keys use your private key to authenticate yourself instead of a password on the remote server, so if you are one of those people who are worried about SSH brute-forcing, if you use SSH keys, you can disable password SSH authentication altogether and not care about those SSH brute-force attempts you see in your logs. When I used to set up SSH key pairs, I wouldn't provide a passphrase to unlock the key. Without a passphrase, I could just ssh in to a machine without typing any sort of password—a case where you can increase security against brute-force SSH attacks while also increasing your convenience.

Of course, the problem with skipping the passphrase when you generate SSH keys is that all of your security relies on keeping your private key (usually found at ~/.ssh/id_rsa or ~/.ssh/id_dsa) secret. If others were able to get a copy of that file, they could log in to any machine to which you distributed the public key. Lately I decided I didn't like that kind of risk, so when I generate SSH keys, I now use a passphrase. This means if others got my private key, they couldn't immediately use it, but it also means I now have to type in a passphrase to use my SSH key. This is less convenient, but I've found that by using SSH agent, I can get back to a similar level of convenience but with a few added bonuses that I discuss in this column.

On most systems that use sudo, after you type in your sudo password, it is cached for some period of time, so if you run a few sudo commands in a row, you don't have to keep typing in your password. SSH agent works in a similar way for SSH passphrases, caching your unlocked key in memory for a defined period of time. This is particularly useful if, like me, you use Git on a routine basis with SSH—it would be a pain to have to type in your passphrase every time you do a git push or git pull. So for instance, if I wanted to cache my passphrase for 15 minutes, I could type:

$ ssh-add -t 15m

Then after I provide my password a single time, it would be cached for the remainder of SSH commands I run within that 15 minutes, after which it would expire.

Because you are prompted for a password after the timeout you set expires, one of the first uses that came to mind for the ssh-add command was an alarm clock of sorts. Sometimes when you are deep in your work, you can forget to do things like eat lunch. What I like to do when I start work for the day is calculate how long until I'd like to break for lunch and set ssh-add to that. For instance, if I start work at 9am, and I want to break for lunch at noon, I would just type:

$ ssh-add -t 3h

Then when noon rolls around, I'll notice, because my next git push or pull, or my next SSH session, will prompt me for a password. Currently I take a ferry into work, and the ferry has a fixed time that it leaves. I know I need to leave the office around 5:30pm to catch that ferry, so once I get back from lunch, I calculate how many hours (or minutes if I want to be that fine-grained) until then and run a new ssh-add command. This alarm clock even has a sort of snooze feature where I can run another ssh-add command to add an extra nine minutes if I want to finish up something before I leave.

Of course, the traditional nice feature SSH agents give you is the ability to forward on your credentials to a server you have logged in to. When you are a sysadmin, you often run into an issue where you'd like to scp a file between servers, but if you have disabled password authentication for SSH (and you should), that could mean putting your private key on your servers, which you may not want to risk. With SSH agent forwarding, your SSH credentials from the private key on your local machine are forwarded to a machine you ssh in to, in RAM, and if you ssh to another machine from there, it will use those credentials.

There is a potential risk with agent forwarding. I think the ssh_config man page says it best:

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

All that said, to use agent forwarding, just add -A to any SSH command you normally would run:

$ ssh -A user@remotehost

Alternatively, you also can set the ForwardAgent setting in a local SSH config file, so you can control which hosts automatically get agent forwarding and which don't.

I love it when adding security can add convenience. While adding a passphrase to my SSH key potentially could have added a big inconvenience in the name of security, I think the benefit of an alarm clock, plus the general ability of ssh-agent to allow me to forward credentials to remote servers without having to risk compromising my private key far outweighs any inconveniences of managing a passphrase or SSH keys in general.