Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Jakuje opened this issue Sep 24, 2020 · 8 comments
Closed

Comments

@Jakuje
Copy link
Contributor

Jakuje commented Sep 24, 2020

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
Copy link
Contributor

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
Copy link
Contributor Author

Jakuje commented Apr 11, 2021

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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

@andreboscatto
Copy link
Contributor

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

@andreboscatto andreboscatto closed this as not planned Won't fix, can't repro, duplicate, stale Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants