Email: ssh-agent abuse

From: "Charles Karney" <ckarney@sarnoff.com>
Reply-To: ckarney@sarnoff.com
To: drobbins@gentoo.org
Subject: ssh-agent abuse
Date: Fri, 7 Sep 2001 11:15:07 -0400 (EDT)

I read your IBM developerworks article on ssh-agent with interest.
Unfortunately, you ignore the ability to forward authentication requests
from a remote machine to a local ssh-agent.  Your description of keychain
encourages using ssh-agent on remote machines which is basically insecure.

ssh-agent should be run ONLY the computer you first connect to.  Hopefully
this is a trusted machine with good security (e.g., a personal Linux PC).

Login in with kdm/xdm or whatever (I usually do this only ONCE per day).
~/.xsession contains

    #! /bin/sh
    eval `ssh-agent -s
    ssh-add < /dev/null &
    # start clients in background
    # start window manager in foreground
    eval `ssh-agent -s -k`

ssh-add in this context pops up an X window for the passphrase.  Thereafter
I use agent-forwarding (ssh -A) to maintain the connection to this
ssh-agent from remote computers.  (There's also a script, xssh, that I
wrote floating around the internet that automates creating windows on
remote computers.)

Advantages:

(1) the private key is stored ONLY on the trusted machine (prevents
    cracking attempts on the key)

(2) ssh-agent only runs on the trusted machine (prevents a remote intruder
    from dissecting the memory image of ssh-agent)

(3) you only type the pass-phrase on the trusted machine (prevent keystroke
    loggers from getting your passphrase)

(4) ssh-agent evaporates when you terminate your session (prevents a
    burglar in your home during a vacation from gaining access to your
    keys)

This scheme doesn't help your example of authenticating cron jobs.  I don't
know whether this is a problem typical users will run into.  Alternatives
are: (1) set up cron entries on the remote machines; (2) use ssh keys which
are NOT passphrase protected but restrict their use with the from-host and
command options in authorized_keys.  I can envision cases where these steps
may not be adequate (syncing file systems, data backup), and then using a
long-running ssh-agent would be appropriate.

In your documentation for keychain, you run ssh-agent on a remote node
cvs.  Now maybe you can trust this host.  But a random user connecting to a
University's compute server with 5000 accounts should NOT make this
assumption.  It's fairly likely that there are the occasional root exploits
on this server and then running keychain poses a considerable risk.

I realize that agent forwarding involves some risks but these are a lot
less than using ssh-agent remotely.

I hope this helps!

-- 
Charles Karney                  Email:  ckarney@sarnoff.com
Sarnoff Corporation             Phone:  +1 609 734 2312
Princeton, NJ 08543-5300        Fax:    +1 609 734 2586