support for Kerberos credential cache locations other than FILE:?

[James Ralston]

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?

_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Petr Lautrbach]

On 12/04/2014 12:22 AM, James Ralston wrote:
> 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.

It seems to work for me using rhel-7's openssh sshd:

tom@ipa-server $ klist
Ticket cache: DIR::/tmp/597000004/tkthx4K48
Default principal: tom@VIRT

Valid starting Expires Service principal
12/10/2014 19:08:41 12/11/2014 19:08:41 krbtgt/VIRT@VIRT

12/10/2014 19:08:50 12/11/2014 19:08:41 host/rhel-7-devel.virt@VIRT



tom@ipa-server $ ssh -o GSSAPIDelegateCredentials=yes
t...@rhel-7-devel.virt
Last login: Wed Dec 10 19:29:31 2014 from master.virt



tom@rhel-7-devel $ klist
Ticket cache: KEYRING:persistent:597000004:krb_ccache_t0MhS7l
Default principal: tom@VIRT

Valid starting Expires Service principal
12/10/2014 19:29:50 12/11/2014 19:08:41 krbtgt/VIRT@VIRT


And using sshd from stock openssh, it works for me too:

tom@ipa-server $ ssh -o GSSAPIDelegateCredentials=yes -o
GSSAPIAuthentication=yes t...@rhel-7-devel.virt
Last login: Wed Dec 10 19:35:22 2014 from ipa-server.virt

tom@rhel-7-devel $ klist
Ticket cache: FILE:/tmp/krb5cc_597000004_rubDAg07mz
Default principal: tom@VIRT

Valid starting Expires Service principal
12/10/2014 19:44:19 12/11/2014 19:08:41 krbtgt/VIRT@VIRT

and sshd logs show:
sshd[27716]: debug1: Setting KRB5CCNAME to
FILE:/tmp/krb5cc_597000004_rubDAg07mz

> ...

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

Is it possible that you don't use GSSAPIAuthentication but e.g.
PublicKeyAuthentication? Can you see an attempt to send credentials in
ssh client logs? Using 'ssh -vv ...' might help.

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

Please try attached patch or krb5_cc_default_name branch at [1].

It adds support for using Kerberos credential cache locations based on
system wide configuration in /etc/krb5.conf. It tries to read a value of:

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

and parse it. If it's not able to get the value or parse it, it falls
back to the original FILE: template.

The patch also adds support for DIR and KEYRING types.


[1]
https://github.com/bachradsusi/openssh-portable/tree/krb5_cc_default_name

Petr
--
Petr Lautrbach