James Ralston
2014-Dec-03 23:22 UTC
support for Kerberos credential cache locations other than FILE:?
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?
Petr Lautrbach
2014-Dec-10 19:02 UTC
support for Kerberos credential cache locations other than FILE:?
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>