openssh unix dev - Jun 2024 - kerberos default_ccache_name with sssd

Good day everyone,

I am currently testing integrating kerberos into our MMR openldap cluster
and things have gone well so far.

I can ssh to my test clients using my kerberos credentials then ssh using
GSSAPI to other hosts as defined in my principals using my ticket,
achieving SSO.

*I wanted to see if I could make the cache file user-specific, instead of
the default location (/tmp/krb5cc-blabla).*

I configured sssd.conf with:
krb5_ccachedir = %h
krb5_ccname_template = FILE:%d/.krb5cc_%U

I configured krb5.conf with:
[libdefaults]
    default_ccache_name = FILE:/home/%{username}/.krb5cc_%{uid}

My sshd_config has the following:
KerberosAuthentication yes
KerberosOrLocalPasswd no
KerberosTicketCleanup yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes
UseDNS yes

*What I noticed:*
When I ssh to the host I can see that klist shows my cache file under /tmp:
Ticket cache: FILE:/tmp/krb5cc_2000_tgiettMBSK
Default principal: jdoe at DOMAIN.NET

Valid starting       Expires              Service principal
06/06/2024 09:06:40  06/07/2024 09:06:40  krbtgt/DOMAIN.NET at DOMAIN.NET
renew until 06/06/2024 09:06:40

If I instead `su` to the user then `echo pass | kinit` my cache file is
respected:
[root at krbhost3 ~]# su - jdoe
[jdoe at krbhost3 ~]$ klist
klist: No credentials cache found (filename: /home/jdoe/.krb5cc_jdoe)
[jdoe at krbhost3 ~]$ echo password | kinit
Password for jdoe at DOMAIN.NET:
[jdoe at krbhost3 ~]$ klist
Ticket cache: FILE:/home/jdoe/.krb5cc_jdoe
Default principal: jdoe at DOMAIN.net

Valid starting       Expires              Service principal
06/06/2024 09:08:03  06/07/2024 09:08:03  krbtgt/NWK.JWM2.NET at DOMAIN.NET
renew until 06/06/2024 09:08:03

So it seems that sssd does as configured and places the cache file in the
correct location but when I ssh into the host, it goes to the default
location.

I also tried setting the KRB5CCNAME environment variable in
/etc/sysconfig/sshd file but sshd still prefers the defaults.

I am using pam_sss and not pam_krb5. (authselect select sssd with-mkhomedir
--force)

*My environment: (3 hosts total)*
rockylinux9: (x2)
OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022
krb5-server-1.21.1-1
sssd-2.9.4-6
symas-openldap-servers-2.6.7-2

rockylinux8: (1x)
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
krb5-server-1.18.2-27
sssd-2.9.4-3

Not sure if this is a redhat issue (since openssh is older on my systems)
or a misconfiguration on my part.

Any input is very much appreciated.

Best,
Dave

Dave Macias wrote on 6. June 2024 15:26 (GMT +02:00):
> So it seems that sssd does as configured and places the cache file in the
> correct location but when I ssh into the host, it goes to the default
> location.
I think the only way sshd influences Klist/kinit is via the environment variable
(if it?s using the same library path). Are you sure it is not present in both
session variants?

I would check the env and if it has no difference, strace klist in both
scenarios.

Gru?
Bernd
? 
https://bernd.eckenfels.net

On 6/6/2024 8:26 AM, Dave Macias wrote:
> *I wanted to see if I could make the cache file user-specific, instead of
> the default location (/tmp/krb5cc-blabla).*
SSH is creating a separate ticket cache file for each login session and owned by
the user.
This has been the preferred way to do this for decades.
https://kerberos.mit.narkive.com/YJB4Hshz/krb5ccname-and-sshd

Your: "Ticket cache: FILE:/tmp/krb5cc_2000_tgiettMBSK" looks like it
is set by sshd and your environment should have a KRB5CCNAME with that name.
If you share the ticket cache between multiple login sessions, when the first
session ends,
the "GSSAPICleanupCredentials yes" will cause the shared ticket cache
to be deleted. Using /tmp means the cache is destroyed upon a shutdown/restart.
/tmp is also a local file system. /home may be on
a network disk which has other issues.
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-- 

  Douglas E. Engert  <DEEngert at gmail.com>