Secret Agent Man
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
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.
SSH Alarm Clock
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
to add an extra nine minutes if I want to finish up something before I
SSH Agent Forwarding
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
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.
Limited Time Offer
Take Linux Journal for a test drive. Download our September issue for FREE.
Topic of the Week
The cloud has become synonymous with all things data storage. It additionally equates to the many web-centric services accessing that same back-end data storage, but the term also has evolved to mean so much more.