KCM: Support for per-session credential cache, similar to KEYRING:session:

[Jakuje]

This feature request comes from the red hat bugzilla [1].

The SSH login using GSSAPI authentication with credential forwarding (GSSAPIAuthentication yes and GSSAPIDelegateCredentials yes) or kerberos authentication (KerberosAuthentication yes) create a credential cache, that makes sense in a particular session.

Originally, it used to be only FILE: type under tmp, which just works, but does not look very good from security point of view. Now, we support any other types (after #876 also KCM:), but these come from krb5.conf's default_ccache_name, which is generally per user credential cache, which is not a good fit for remote logins, especially if different principals are logging into the same linux account.

Similar feature exists in KERING:session but it is not usable for ssh at this moment because we need to store the credential before the actual user keyring session is opened during the pam session execution, but this is a different problem we will have to look into.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1843240

[joakim-tjernlund]

Similar feature exists in KERING:session but it is not usable for ssh at this moment because we need to store the credential before the actual user keyring session is opened during the pam session execution, but this is a different problem we will have to look into.

I always woundered why openSSH needs to auth in such an odd order, makes life much harder others.
Anyone ever checked if openSSH could be changed ?

[Jakuje]

Probably because openssh was not built around PAM as the other modern linux software.

But simply changing OpenSSH to do the credential forwarding later is not going to address the original issue as it is a "chicken-egg" problem -- the session part of of the pam stack sets up the kernel keyring session and following modules already expect the forwarded credential being present. Unless ssh would inject its own pam module between these two (and manage to pass the forwarded credentials to it).

[joakim-tjernlund]

I see, something needs to be done at the ssh side then before ssh ticket problems can be resolved.

One this I have noted is that sssd renewal does not seem to work even for login tickets.
I set krb5_renew_interval = 1m but no renewal happens, klist show the same values whenever I look.
Got pam_sss.so in my PAM conf too

[alexey-tikhonov]

One this I have noted is that sssd renewal does not seem to work even for login tickets.

IIUC, #5450 should address this.

[joakim-tjernlund]

One this I have noted is that sssd renewal does not seem to work even for login tickets.

IIUC, #5450 should address this.

This test was without KCM, just FILE: protocol. Should not that work for simple cases like this?

[joakim-tjernlund]

I left the session alone over night and now a got a refresh(I think)
Started with:
11/04/21 18:29:37 12/04/21 04:29:37
Now I got:
12/04/21 10:28:49 12/04/21 20:28:49

It seems like sssd does not respect the renew settings, but is using some automatic refresh algo.

[alexey-tikhonov]

We need to figure out if this is still relevant taking into account RHBZ 1843240 is closed.

[andreboscatto]

Update: We don't have any drivers or enough justification to spend efforts in this specific use case right now.