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.) On Wed, 2015-06-24 at 15:27 -0500, Ben H wrote: > 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 > <ballb...@sinenomine.net> wrote: > 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 > allber...@gmail.com > ballb...@sinenomine.net > unix openafs kerberos infrastructure xmonad > http://sinenomine.net > > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix openafs kerberos infrastructure xmonad http://sinenomine.net ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos