support for Kerberos credential cache locations other than FILE:?

[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 at ipa-server $ klist
Ticket cache: DIR::/tmp/597000004/tkthx4K48
Default principal: tom at VIRT

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

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



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



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

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


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

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

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

Valid starting       Expires              Service principal
12/10/2014 19:44:19  12/11/2014 19:08:41  krbtgt/VIRT at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-support-for-using-kerberos-credential-location-s.patch
Type: text/x-patch
Size: 8237 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141210/eaabbdb7/attachment.bin>