help with persistent ccache

[Ben H]

I'm trying to understand how the newer KEYRING:persistent cache is working
in relation to interactive and GSSAPI SSO.

Using Centos 6.4 and 7.1.

My 7.x box is using the default configuration of:
default_ccache_name = KEYRING:persistent:%{uid}


Please take a look at the below session. What we see is that when
performing an interactive login (no tickets) from centos64 to centos71, a
persistent cache is seemingly not created (or at least not found).
However, if I initialize a ticket via kinit for my user and then SSH using
GSSAPI it appears to have initialized the persistent cache.
Obviously this is problematic because it means the first interactive login
to a 7.x box fails to create a cache and thus can't get a ticket for future
SSO operations.
It appears that if I manually kinit following the first login the
persistent cache is created.

Why is not cached initialized on interactive login and an additional manual
kinit is required?

thanks!

[root@centos64-01 ~]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@centos64-01 ~]# ssh spp...@centos71-01.spptech.com
Password:
Last login: Wed Jun 24 14:59:06 2015 from centos64-01.spptech.com
[sppuser@centos71-01 ~]$ klist
klist: Credentials cache keyring 'persistent:402243354:402243354' not found
[sppuser@centos71-01 ~]$ exit
logout
Connection to centos71-01.spptech.com closed.

[root@centos64-01 ~]# kinit sppuser
Password for spp...@SPPTECH.COM:
[root@centos64-01 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: spp...@SPPTECH.COM

Valid starting Expires Service principal
06/24/15 14:59:34 06/25/15 00:59:37 krbtgt/SPPTE...@SPPTECH.COM
renew until 07/01/15 14:59:34
[root@centos64-01 ~]# ssh spp...@centos71-01.spptech.com
Last login: Wed Jun 24 14:59:21 2015 from centos64-01.spptech.com
[sppuser@centos71-01 ~]$ klist
Ticket cache: KEYRING:persistent:402243354:402243354
Default principal: spp...@SPPTECH.COM

Valid starting Expires Service principal
06/24/2015 14:59:49 06/25/2015 00:59:37 krbtgt/SPPTE...@SPPTECH.COM
renew until 07/01/2015 14:59:34

[Brandon Allbery]

On Wed, 2015-06-24 at 15:10 -0500, Ben H wrote:
> Why is not cached initialized on interactive login and an additional
> manual
> kinit is required?

This may have nothing to do with keyring ccache, but only with a
misconfigured PAM stack that is not creating a ccache with the ticket
from login.

Alternately it could mean that login is running the session PAM stack in
the wrong context, so the wrong keyring is created. I would check the
first part before trying to diagnose the second, though.

--
brandon s allbery kf8nh sine nomine associates
allb...@gmail.com ball...@sinenomine.net
unix openafs kerberos infrastructure xmonad http://sinenomine.net

[Ben H]

Thanks for the quick reply Brandon.

I don't have this issue if I remove the "default_ccache_name = KEYRING:
persistent:%{uid}" and thus default back to the file based cache. In that
case, the cache is created properly on login in /tmp,
That would indicate to me that PAM is properly creating a cache.

Would this indicate that it isn't the PAM stack not creating the cache or
would it more likely be the PAM module not utilizing the keyring properly?
Or perhaps the PAM module doesn't understand how to work with the keyring?

thanks.


On Wed, Jun 24, 2015 at 3:21 PM, Brandon Allbery <ball...@sinenomine.net>
wrote:

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

[Brandon Allbery]

Hard to say, but I would expect the keyring interaction to be in the
Kerberos libraries so a problem at that level might indicate that the
PAM module is linked against a different version of the Kerberos
libraries. This would seem unlikely if it is using shared libraries
(which you can check with ldd).

It is more likely that the correct context for the keyring is not yet
established when the PAM session stack is run, so it is either creating
the keyring but in the wrong place (keychain) or getting an error while
trying to create it. This would be controlled by when sshd runs the PAM
session stack relative to other parts of session establishment, and
might depend on details of how the Linux keychain is associated with a
user process. It could also be related to recent sshd features such as
sandboxing, where the keyring might e.g. be created inside the sandbox
instead of in the user session.

(It also would not be the first time that sshd turned out to do things
slightly incorrectly; in the (somewhat distant) past this has led to
file ccaches owned by root, for example.)

[Ben H]

Thanks again Brandon.

Yes I know that the PAM module is linked against libraries pre 1.12 that
don't support the persistent option. These are different from the system
libraries that sshd is linked against.
I'm going to work on seeing if updating those libraries fixes this, or if I
can use a different PAM module that is using more up to date libraries.

I'll try to update this when that happens, but it may be a while off. For
now I think we will be reverting to the FILE based cache.


On Wed, Jun 24, 2015 at 3:35 PM, Brandon Allbery <ball...@sinenomine.net>