Red Hat Bugzilla – Bug 1010690
Unable to access credential cache outside of homedir
Last modified: 2013-09-23 14:51:58 EDT
Description of problem: This may be intentional, but if it is it causes some problems. I know you folks were doing work on moving the credential cache. When running klist outside of the homedir the credential cache is not found. This means that using utilities like ssh and scp only work with kerb inside of the homedir. Version-Release number of selected component (if applicable): krb5-workstation-1.11.3-9.fc20.x86_64 How reproducible: erinn@thin-mint ~ $ klist Ticket cache: FILE:(null) Default principal: erinn@FOO.COM Valid starting Expires Service principal 09/20/2013 11:23:20 09/21/2013 11:23:15 krbtgt/FOO.COM@FOO.COM 09/20/2013 11:26:13 09/21/2013 11:23:15 host/foo.foo.com@FOO.COM 09/20/2013 13:16:52 09/21/2013 11:23:15 HTTP/foo.foo.com@FOO.COM erinn@thin-mint ~ $ cd .. erinn@thin-mint /home $ klist klist: No credentials cache found (ticket cache FILE:(null)) erinn@thin-mint ~ $ kinit Password for erinn@FOO.COM: erinn@thin-mint ~ $ ssh foo <Connection works using kerb> erinn@thin-mint ~ $ cd .. erinn@thin-mint /home $ ssh cc <Connection falls through kerberos>
Sorry that last bit should be ssh foo and it fails again. Failed to sanitize all the host names :).
What is $KRB5CCNAME set to? Is it being set for you when you log in? If so, which PAM module is configured? Is there a "default_ccache_name" set in the [libdefaults] section of the /etc/krb5.conf file?
erinn@thin-mint ~ $ cat /etc/krb5.conf #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = FOO.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] ABAQIS.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .foo.com = Foo.COM foo.com = FOO.COM erinn@thin-mint ~ $ echo $KRB5CCNAME (null) No modifications are made, this is pretty much stock from what ipa-client-install configures.
Hmm, it looks like your session is attempting to use a file named "(null)" as the ccache, and because it's not an absolute path, you need to be in the same directory you were in when it was created in order to use it. Whatever's setting KRB5CCNAME to that value is doing something wrong. Are you logging in to your session with your Kerberos password? If so, can you paste in the contents of your /etc/pam.d/system-auth and /etc/pam.d/password-auth files? That'll help us figure out if it's something gone wrong in pam_krb5 or pam_sss/sssd.
erinn@thin-mint ~ $ cat /etc/pam.d/password-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so erinn@thin-mint ~ $ cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
Okay, it looks like that KRB5CCNAME value is coming from pam_sss. We'll need to rope in the sssd maintainers. Reassigning.
*** This bug has been marked as a duplicate of bug 1010553 ***