credentials caching mechanism, ssh gssapi-with-mic

[Booker Bense]

On Tue, Jul 1, 2014 at 9:34 AM, Matt Garman <matthew.garman at gmail.com>
wrote:

>  As far as I can tell, re-creating the keytab
> file causes the key version number (“KVNO”) to be incremented.
>
>
The "standard" way to deal with this problem is to keep both key version
numbers in the keytab file on the machine. The KDC only keeps one version
of the key, so there is no simple way to recreate the old key using KDC
data.

Heimdal has a kadmin protocol that allows you to download the key directly,
thus working around this problem.

The only solution I can see for your reinstall problem is to make a very
short lifetime on the service tickets.



> 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?
>

NFSV4 has a daemon that basically trolls /tmp looking for kerberos tickets
and caches those credentials from the NFS daemons.

- Booker C. Bense