support for Kerberos credential cache locations other than FILE:?

James Ralston qralston+ml.openssh-unix-dev at andrew.cmu.edu
Thu Dec 4 10:22:23 EST 2014


The MIT Kerberos library has supported credential cache locations
other than "FILE:" for a while now:

    http://web.mit.edu/kerberos/krb5-devel/doc/basic/ccache_def.html

In fact, RHEL7 sets the default credential cache to use the kernel
keyring, via the new(ish) "default_ccache_name" option in
/etc/krb5.conf:

    [libdefaults]
    default_ccache_name = KEYRING:persistent:%{uid}

However, this will break forwarding Kerberos credentials via
GSSAPIDelegateCredentials.  But I'm not sure why, since openssh
hardcodes the location of the Kerberos credential cache in
auth-krb5.c:

        ret = snprintf(ccname, sizeof(ccname),
            "FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid());

        tmpfd = mkstemp(ccname + strlen("FILE:"));

        ...

        return (krb5_cc_resolve(ctx, ccname, ccache));

Based on this, I would expect openssh to blast over the library
default, but when I test, I see $KRB5CCNAME set to (e.g.)
KEYRING:persistent:12345, but without credentials in it.  (And tracing
the sshd process shows that it never attempted to create any
file-based credential cache.)

So, two questions:

First, does anyone know what happens to the credential cache openssh
creates when the library default location is a keyring?  Openssh isn't
logging any errors, so I don't think the various krb5 library
functions are failing.  Has anyone else already played around with
this?

Second, is there a reason why openssh hardcodes the ccname location,
instead of using krb5_cc_default_name() to obtain the library default?

The only reason I can see for doing this is because if the library
default starts with FILE: or DIR:, then you need to append
"XXXXXXXXXX" (if necessary) and then use mkstemp() to get a
non-predictable location.  So that would be a little more effort than
what openssh currently does.

However, this would enable openssh to support Kerberos credential
types other than "FILE:", so I'd argue it's worth it.

Am I missing something?  Is there a specific reason why openssh
doesn't already do this?



More information about the openssh-unix-dev mailing list