Re: screen and ssh agents + agent forwarding (+ $DISPLAY)

[Phil!Gregory]

* Jeremy Chadwick <address@hidden> [2005-02-12 19:29 -0800]:
> Anyone here who has tried to use GNU screen alongside an ssh agent
> will know how painful it is to get things to work properly, especially
> when using the forwarding mechanism of ssh agents.  It's a complete
> mess.

I've thought about this before, and some more now.  Here are my thoughts,
with something of a solution following (skip the next paragraph if you
don't want to read my ramblings on the subject):

ssh agent information is maintained as environment variables.  Michael
points out that screen cannot modify its children's environments after
spawning, so any solution will have to involve shells fixing themselves.
screen should be updated, too, so that new children will get the most
current values (unless you simply don't want to worry about non-shell
windows).  The hard part then becomes choosing the correct agent.  This
can be managed easily if you don't multi-attach, and semi-easily if you
multi-attach but never use multiple displays simultaneously (e.g. you go
to work, 'screen -x', use screen, and then detach before you go home).
Once you start switching displays while leaving them attached, though, I
don't see a way for anything to track what to do.  Only screen knows which
display input is currently coming from, and there's no way for anything to
get that information from screen or for screen to tell anyone.  And the
most pathological case involves someone starting to type a command from
one display, then finishing it and pressing enter from a different one.

So, as I see it, the best approach is: when you start screen from an ssh
session, have it note and record the necessary information, indexed by
$SSH_CLIENT; keep track of your current "location", when that changes, you
run a command that changes the location; have the shell check the location
periodically and update its environment if the location changes.

Details for my particular setup (and not only is this just for my stable
of programs, I done a minimum of testing; YMMVG):

I already use a wrapper script for starting screen, so in that script
goes:

  if [ "$SSH_CLIENT" != "" ]; then
    IDXHOST=`echo $SSH_CLIENT | cut -d ' ' -f 1`
    mkdir -p ~/.screen/$IDXHOST/
    ln -sf $SSH_AUTH_SOCK ~/.screen/$IDXHOST/ssh-auth-sock
    ln -sf ~/.screen/$IDXHOST/ssh-auth-sock ~/.ssh-auth-sock
    SSH_AUTH_SOCK=~/.ssh-auth-sock
  else
    IDXHOST=`hostname -i`
    mkdir -p ~/.screen/$IDXHOST/
  fi
  echo $DISPLAY > ~/.screen/$IDXHOST/display
  cp ~/.screen/$IDXHOST/display ~/.display

Then there's the setloc shell script:

  #!/bin/sh
  local LOCATION=$1
  if [ "$STY" = "" ]; then
    echo "Not running in screen." 1>&2
    exit 1
  fi
  if [ ! -d ~/.screen/$LOCATION ]; then
    echo "There's no state recorded for $LOCATION." 1>&2
    exit 1
  fi
  if [ ! -e ~/.screen/$LOCATION/ssh-auth-sock ]; then
    echo "That SSH session appears to have gone away." 1>&2
    exit 1
  fi
  ln -sf ~/.screen/$LOCATION/ssh-auth-sock ~/.ssh-auth-sock
  cp ~/.screen/$LOCATION/display ~/.display

And, finally, the shell's correction function.  I use zsh, so the best
place for this is in my preexec().  bash users will have to put it in
$PROMPT_COMMAND, and the change won't take effect until a new prompt has
been displayed after the change.  (With zsh and preexec(), I can do setloc
in one window then switch to another, run a program there, and have it
work properly.):

  preexec () {
    if [ "$STY" != "" -a "$DISPLAY" != "`cat ~/.display`" ]; then
      DISPLAY=`cat ~/.display`
    fi
  }

You can make symlinks in ~/.screen/ for more symbolic names, so you can
e.g. run 'setloc work' instead of 'setloc 127.126.128.134' or whatever.

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
<Beeth> Girls are like internet domain names, the ones I like are already
        taken.
 <honx> well, you can stil get one from a strange country :-P
                       -- geekissues.org quote #369
---- --- --