credentials caching mechanism, ssh gssapi-with-mic

Greg Hudson ghudson at MIT.EDU
Tue Jul 1 13:47:35 EDT 2014


On 07/01/2014 12:34 PM, Matt Garman wrote:
> Nothing unusual or surprising so far.  Now, let’s say that particular
> slave server is rebuilt (OS wiped, re-installed, re-configured).  Note
> that the rebuilding process involves re-generating the host keytab
[...]

This is the "destructive service rekeying" problem, as described at:


http://k5wiki.kerberos.org/wiki/Projects/Graceful_recovery_after_destructive_service_rekey

The original assumption was that when services are rekeyed, the old key
version will be retained in the keytab until all outstanding service
tickets are expired.  But of course that's not practical when the server
is completely redeployed.

> Any easy workaround is of course to do a “kdestroy ; kinit” to clear
> out that stale host entry.  However, the above is over-simplified;
> user’s will have dozens of host entries for all their slave machines,
> and we don’t want to clear out those cache credentials (only the
> offending ones).  As far as I can tell, there does not appear to be
> any way to *selectively* remove cached tickets.  Or am I missing
> something?

You are correct, there is not.  It's not usually a big deal to
invalidate the other service tickets; TGS requests are pretty cheap.

> Also: I’m a little unclear on exactly how credentials caching works.
> I get the impression that there is some kind of in-memory caching (at
> the kernel level?) that doesn’t show up in klist.  For example, say
> someone logs into a server (using ssh gssapi-with-mic), launches a
> program that needs to access NFSv4 sec=krb5p shares, and then closes
> that session.  The job stays running---for a while.  After some time
> (seems to be on the order of 8--10 hours), access to the NFSv4 share
> fails.  But in this case, there is no /tmp/krb5cc* file for that
> particular user… so clearly there is some kind of credentials caching
> going on, but where is it?  And how long does it last?

Some of this is speculative because it has to do with the kernel's NFS
implementation, which I'm not an expert on.  That said:

Service tickets are used to negotiate GSS security contexts (or raw
libkrb5 auth contexts, but that case is irrelevant to SSH and NFS).  A
GSS security context usually has its own subsession keys separate from
the ticket session keys.  A security context typically lasts the
lifetime of a connection or protocol equivalent.  The server application
may or may not enforce a restriction that the context stops working upon
expiry of the ticket which was used to create the context.

So, I am guessing that the NFS client within the kernel is keeping
around a GSS security context, and the NFS server allows that to
continue working until the ticket expires, at which point the client
can't establish a new context and the job breaks.

It is possible that the kernel has a copy of the service ticket for the
NFS client (this is how AFS works; you use the aklog command to push a
service ticket into the kernel as a "token") but I think at this time
that's not how it works.


More information about the Kerberos mailing list