I apologise if this topic has been discussed before, but I have skimmed
the archives and have not found anything relating to it.  This issue
has, on the other hand, been discussed a couple times on the old Yahoo
Groups list, to no avail.

Finding information about this problem is also a real pain, since search
engine queries for the word "screen" will... well... I'm sure you know.
This mail will hopefully place information into a standard location
where future visitors can get information about the problem.

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.

If this is a new issue to you, let me explain the problem, and how GNU
screen modifications can help alleviate this pain.  If you don't want to
read my explanation, and want something more concise, read this:

  http://www-106.ibm.com/developerworks/linux/library/l-keyc3/

SSH agents are essentially "key caches", induced/supported by the SSH
client (such as SecureCRT or PuTTY, or in the case of *IX OpenSSH,
ssh-agent(1)).  When using an agent, environment variables are set up
once the agent is configured.  sshd actually maintains a socket file
in /tmp (usually named /tmp/ssh-<gibberish>/agent.<pid>) when an SSH
agent is used.  This socket is removed when the user logs out (i.e.
sshd detects a disconnect).  Important to note: the <gibberish> and
<pid> I speak of are specific to each SSH connection made to sshd;
they are unique identifiers for that SSH session.

When GNU screen is run, the SSH_AUTH_SOCK environment variable is
imported from the parent shell which started screen, and is kept that
way throughout all future spawned shells within screen.

The problem is that if a user detaches from screen, logs out of the
system, and logs back in, the agent socket created by sshd will no
longer exist; therefore, the SSH_AUTH_SOCK variables within the shells
spawned by screen now point to a non-existent directory and a
non-existent socket file.

Simply put, this breaks SSH agent forwarding.

If my description here does not make sense, please read the following
sites which contain information about the problem:

  http://www.deadman.org/sshscreen.html
  http://www.gentoo.org/proj/en/keychain/index.xml
  http://frogcircus.org/screen/ssh-agent

The above two links contain workarounds for this problem, none of which
truly address the problem -- and in some cases, actually induce MORE
problems due to their methodology.

The most common idea is to overwrite SSH_AUTH_SOCK, pointing to a static
location (such as $HOME/.screen_ssh_sock), which is an actual symbolic
link to the socket file (/tmp/ssh-<gibberish/agent.<pid>).  The
framework to update the symbolic link is done in either .bash_profile
(for bash users) or .login (for csh/tcsh users).

This method has two major flaws:

  a.  Requires the shell to have the ability to detect interactive
      vs. non-interactive login shells.  Not all versions of bash
      support this methodology, resulting in something like scp(1)
      from another host to the host which has the dot-files breaking
      pre-existing symlinks.
  b.  Assumes you will only have one ssh session to the machine the
      dot-files are running on.  I.e. if you're logged into box "foo"
      from home (which has GNU screen attached), leave your machine
      connected, go to work, and ssh into "foo" from work, you will
      completely botch the symlink -- one you go home, you will find
      that the symlink points to the agent socket file created when
      you logged in from work.  You now have to manually remove the
      symlink and point it to the right place for agent forwarding to
      again work.
  c.  A workaround for this method could be to "detect" if you're
      already connected to the machine elsewhere and therefore not
      update the symlink, but this is quite horrible to do: anyone
      who argues with me on this is flat-out wrong.  Period.

I have used this method (rather than using other peoples' example
dot-file scripts, I wrote it myself), and ran into Issue B quite often.
Issue A I encounter at my workplace, with no solution (I do not maintain
the systems, and I have asked for a bash upgrade -- at least to 2.05b --
almost 6 months ago to no avail.  Apparently there are complexities when
it comes to Solaris x86 and 2.05b, and readline/gettext problems with
3.0).

The problem with using keychain is that it needs to be run on the CLIENT
system (where your SSH client is).  keychain does not exist for Windows.

The problem with the third site mentioned is that it has things which,
simply put, do not work: (re: .screenrc modifications which "trick"
screen into re-reading .screenrc on a re-attach; this doesn't work).

I'd like end-users to discuss all of this, and figure out a good
solution for this problem.  I believe that there can be framework added
to GNU screen to alleviate this entire ordeal once and for all.

Thanks.

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.                             |