Search

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
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.

SSH Agent

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
ssh-add command
to add an extra nine minutes if I want to finish up something before I
leave.

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
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:

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.

Kyle Rankin is a Tech Editor and columnist at Linux Journal and the Chief Security Officer at Purism. He is the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia
Hacks and Ubuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including at
BsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.