Refreshing SSH forwarded/delegated credentials
Douglas E. Engert
deengert at anl.gov
Mon Jun 6 11:42:21 EDT 2005
Buck Huppmann wrote:
> hello. sorry to cross-post, but i at least left out openssh-unix-dev@
> this time around
>
> anybody know if somebody's working on the issue of how to refresh cred-
> entials forwarded/delegated to a an SSH session? e.g., if the server
> is using RPCSEC_GSS-flavored NFS and your forwarded (krb5) credentials
> and those credentials expire, that tends to cripple the remote login
> session, no? same sorta thing with AFS, yes? are you just supposed to
> use (Heimdal's) kf/kfd facility?
Yes AFS has the same problem.
>
> Google produces a few hits that seem to have to do with GSSAPI dele-
> gation-refreshing some work of Douglas Engert on the Globus project,
There was some work done with Globus, which included the GSSAPI extensions
that added a delegate at any time function. NCSA also did some ssh mods
that I believed used this feature, but not with Kerberos GSS.
Google for gsi ssh ncsa which will lead to:
http://grid.ncsa.uiuc.edu/ssh/
Do a google for gss extensions to find the Globus gss extensions drafts.
> it seems, but they don't seem to lead to any patches or discussion of
> implementation. and i guess the IETF Kitten working group hasn't even
> standardized a GSSAPI mechanism for adding delegated credentials to a
> context, so the question of refreshing those credentials may not even
> be on their radar (officially)
>
> please stop reading and point me in the right direction if this is
> all leading in the wrong direction
Its a problem, that nees to be addressed.
>
> thanks
>
> --buck
>
> still there?
>
> darn
>
> then i guess i'm interested in stimulating implementation^Wdiscussion
> about how to do it. lowering the level of abstraction to a meaningful
> (for me) instance, for the moment, in the case of forwarded Kerberos
> credentials that aren't themselves renewable, one could conceive of
> any of the following:
>
> 1. a ``subsystem'' to which the connected SSH client could open up
> a session on a separate channel to send asynchronous credential
> updates for it to stick in the credential cache that the ssh-userauth
> exchange set up
>
> 2. a. an agent-type function in the SSH server and client so that the
> server end would sit on the writing side of a named pipe and hold
> the credentials in memory, so that krb5 clients could open the pipe
> up like a credentials cache file and the agent function could make
> a call back to the client-end agent if it determined the cache
> was stale; or,
>
> b. since that's particularly unlikely to work with an implementation
> that's expecting a real file it can read and write to (and might
> be even more improbably on non-UNIX systems), the agent might al-
> ternatively sit around and poll the file cache and take it upon
> itself to make a call back to the client end if the cache is
> ``about to'' expire, and so update the cache asynchronously
>
> in any case, please clue me in. i realize there's a really heady ad-
> mixture here of SSH along with Kerberos concerns, but i thought you all
> might have the wider view that could maybe be focused on this problem
> before i tried to prevail upon the SSH folks to try to figure out how
> to implement it, if such be their will, b/c they don't suffer fools as
> graciously as you all, i gather
>
> thanks
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list