Re: [PATCH] Kerberos support for screen

[Fredrik Tolf]

On Sat, 2005-02-26 at 15:06 -0800, Jeremy Chadwick wrote:
> Fredrik,
> 
> Can this sort-of logic (re: screen keeping one credential cache for
> Kerberos) be applied to the situation pertaining to SSH agents? (see my
> previous thread on the gnu-screen mailing list for details)
> 
> The solution you've proposed sounds, to me, like a good one.  I think
> we all agree it's not the "responsibility" of screen to solve problems
> like these, but there's really no other place it can be solved while
> using screen itself.  Framework for solving this problem, in my opinion,
> is a Good Thing(tm).

As you say, these two problems are very similar in nature. If you want
my honest opinion, stop using ssh-agent and use Kerberos instead. ;-)

If you, as I suspect, don't want to do that, however, your problem can
be solved very similarly. However, it cannot be solved as completely as
with Kerberos.

The ssh-agent is similar to the Kerberos credential cache in that they
both act as a sort of key cache. However, Kerberos' ccache resides
locally on each machine you're logged in to, while ssh-agent run on the
machine you initially logged in to. In other words, there's only one
copy of the ssh-agent, while there can be an arbitrary number of copies
of Kerberos ccaches.

If I were to propose a solution to your problem, it would be to have the
screen back-end create a new socket, export its path in the
SSH_AUTH_SOCK to all subshells (like I do with the KRB5CCNAME variable),
and then proxy all connections to that socket, through the screen
front-end (attacher), to the ssh-agent auth sock that the attacher has
access to.

However, since, like I mentioned, ssh-agent runs on the machine that you
initially logged in to, there is simply no way let the processes running
in the screen session have access to an ssh-agent while the screen is
detached and you're not logged in to the machine where it's running,
whereas the Kerberos ccache can simply be copied and kept by the screen
back-end. That may or may not be a problem for you. If it is, however,
then I see no other choice for you than to switch to Kerberos (which you
should do either way, though ;-) ).

Fredrik Tolf