SSH agent proxy in screen

People commonly encounter problem trying to combine use of screen and
SSH agents. If you start a screen session and then detach it and
reattach it somewhere else, the processes running inside the screen
are still going to query the old SSH agent. Often this SSH agent was
part of a login session that doesn't exist anymore (so requests fail
completely) but sometimes it still exists (worse: your software
querries an SSH agent that is not the one you are running in the
session you are sitting in front of).

There have been various workarounds uses which can be found easily
by searching the web. They fall under these categories:

- helper scripts to fudge up the environment variables when you
reattach.

Example: http://deadman.org/sshscreen.html

Cons: You have to run those scripts in every existing window (screen's
"setenv" function will only affect new windows), and long-lived
software that is already running won't use the new agent (like an
ssh client running under screen that is performing SSH forwarding to
somewhere else.

- running a dedicated agent inside the screen session.

Example: http://teichman.org/blog/2006/02/screen_and_ssha.html

Cons: Your SSH agent should be as close to you as possible (your key
material should be someplace you trust). Your screen session might
not be in such a place. Also, you don't have the ability to use the
same agent as the rest of your (non-screen) apps.

The solution I prefered to see is an SSH proxy agent built into
screen. That is, screen should intercept SSH agent requests. Since it
keeps track of which displays (terminals, sessions) it is attached to,
it should then forward the SSH agent requests to the real SSH agents
that service the sessions that are attaching to the screen session.
The result of this method is that if you detach a screen session and
reattach is somewhere else, SSH agent requests coming from within
the screen session are seamlessly forwarded to a new agent. As a
side effect, when screen is running detached, there is no agent
available at all (this is what you want, from a security point of
view).

I implemented this solution in screen-4.0.2. Your comments are
apreciated on this method. Do you think it's feature bloat? I
think it's very useful. I will send the patch (1248 lines) if
there is some positive response :-)

/*
 * Screen SSH agent proxy
 *
 * Using this feature, Screen acts as an SSH agent on behalf of the
 * processes that run inside the screen session. It does this by
 * creating a new listening socket and propagating its location in
 * the $SSH_AUTH_SOCK variable inside the screen session. The SSH
 * agent is a thin proxy that forwards requests to SSH agents
 * associated with the sessions under which the screen session is
 * attached. When the screen session is detached the SSH agent
 * requests from inside screen are not forwarded anywhere and no
 * keysigning requests can be satisfied (this is what you normally
 * want). If the screen session is attached again from a different
 * location, the agent requests will be forwarded to the new
 * location.
 *
 * Multiply attached sessions: the proxy tries to do something
 * reasonable with each requests. Requests to remove key material
 * are replicated to all attached sessions' SSH agents. Requests
 * to list available keys result in the union of all successful
 * responses. But a request to add a key to an agent will be
 * satisfied by the first agent that reports success.
 *
 * To attach to a screen session without making the attaching
 * session's SSH agent available inside the screen session,
 * suppress your $SSH_AUTH_SOCK environment variable:
 *
 * SSH_AUTH_SOCK= screen -r
 *
 */

-Phil