Bug 1010690

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 ***