Getting paranoid about ssh-agent

Wednesday, 09. 1. 2010  –  Category: vague

A colleague asked me about my SSH setup, which uses different SSH agents for each set of keys that I use (I tend to use a different keypair for each client I work with) and also makes ssh-agent confirm with me each time a key is used.

What’s the point of all that? Because it’s trivially easy to take over someone else’s SSH agent if you have root on a box they’re forwarding to:

$ ssh-add -l
1024 c7:ba:59:92:98:40:f4:53:75:e3:7f:03:fc:0e:3b:bd /Volumes/key/ssh/id_dsa-zomo-bbc (DSA)
$ sudo -i
# ls -ld /tmp/ssh-*
drwx------ 2 victim admins 4096 Aug 27 16:20 /tmp/ssh-bsKJhM8501
drwx------ 2 me  admins 4096 Sep  1 09:25 /tmp/ssh-NpAJW14419
# SSH_AUTH_SOCK=/tmp/ssh-bsKJhM8501/agent.8501 ssh-add -l
1024 7a:0a:df:bb:ab:cd:af:e1:04:97:cd:05:34:8c:b4:68 /home/victim/.ssh/id_dsa (DSA)

By setting SSH_AUTH_SOCK to their agent’s forwarding socket you can gain use of their agent for onward logins. Laws may apply.

Update: To be clear, the victim and the attacker here are both logged onto a remote host over SSH and using SSH agent forwarding. This isn’t a discussion of the risks of someone having root privilege on a machine where your SSH agent process runs (and your private SSH keys reside).

To mitigate this risk, I use a collection of scripts that do two things

  1. Run different SSH agents for different keys, so that a compromised agent
    has only limited use (eg: root on client A’s hosts can’t use it access
    client B’s hosts).

  2. Require ssh-agent to prompt for confirmation before it uses a key, so that
    a compromised agent stands less chance of being exploited (if I’m away or I decline the request then nothing happens).

They’re here: http://github.com/zomo/ssh-bits. No points for elegance, but they scratch the itch.

3 Responses to “Getting paranoid about ssh-agent”

  1. Tony Finch Says:
    September 1st, 2010 at 4:30 pm

    Nice.

    I have a setup which automatically deletes the keys from my ssh agent a short time after my screensaver locks the screen, to make transitive attacks harder if my workstation is compromised when unattended. I have a script run by xautolock which wraps xlock, and forks a background shell which clears the ssh keys after a few minutes. (The delay makes it less annoying to return after a short break.) When xlock finishes (when the screen is unlocked) it runs ssh-add. There are a couple of files used as interlocks, so that it doesn’t prompt to re-add the keys if they haven’t been deleted, and it doesn’t delete the keys if the screen has already been unlocked.

  2. mc0e Says:
    June 3rd, 2013 at 3:01 pm

    Maybe also worth a mention that while this can happen through your desktop/laptop machine being compromised, at that point it’s probably game over anyway. The risk you’re avoiding here is one that arises by forwarding your agent connection.

    By all means take steps to limit the risk from these forwarded agent connections, but the biggest part of this risk is sysadmins who turn agent forwarding on by default. better to only engage it when it’s needed. (ssh -A host)

  3. jon Says:
    June 3rd, 2013 at 3:52 pm

    Thanks. I only had agent takeover on remote systems in mind, I’ll add a note to make that clearer.

    I agree you should only connect with agent forwarding when necessary; I tend to specify -A on a per-server basis either in .ssh/config or the abstracted YML file I use.

Leave a Reply