How to authenticate through OpenSSH then sudo with only one Ticket Service (Kerberos TGS host/fqdn)
By now, we are using OpenSSH GSSAPI authentication on all of our servers (Debian from 10 to 12).
Then we sudo -i, using ldap authentication (through sssd-ldap).
I would like to get rid of the ldap authentication and rely on GSSAPI only, both for OpenSSH and Sudo.
The idea is to to forward Ticket service to Openssh (host/fqdn), keep it in the credentials cache (typically /tmp/krb5…) and keep that TGS to also authenticate sudo (I found that pam_sss_gss.so could authenticate sudo with GSSAPI).
The problem is…OpenSSH destroys the Ticket service once it’s validated.
Here are my questions:
- Is there a way to keep the ticket service forwarded to openssh inside a credential cache? It would help me to authenticate sudo afterward.
- If 1 is not possible (and i guess it is indeed not), are there any security concerns about forwarding TGT on all of our servers? (TGT lifetime is 4 hours). I would have to open a flow between servers and KDC port 88 on our firewall.
- I’d rather avoid NOPASSWD inside sudoers, but if members of group sudo authenticate via kerberos, are there any security concerns about putting NOPASSWD inside sudoers for that group?
- Let me know whether you have other ideas, i would really appreciate it.
Thank you.
Is there a way to keep the ticket service forwarded to openssh inside a credential cache? It would help me to authenticate sudo afterward.
No, there’s no option to do that. (It would be possible in theory, but it’s not an implemented function.)
However, it might be possible to use PAM to acquire a "S4U2self" ticket, where the service uses its own keytab to get a ticket to itself "on behalf of" the user. (See e.g. kvno -I.)
(Also it’s called a service ticket, not ticket service.)
If 1 is not possible (and i guess it is indeed not), are there any security concerns about forwarding TGT on all of our servers? (TGT lifetime is 4 hours).
There are, very similar to SSH agent forwarding. Even though the long-term credentials cannot be stolen, the 4-hour TGT in theory could be stolen (and extended all the way up to their renewable lifetime – not just up to their normal lifetime).
It’s up to you to decide whether that’s a significant concern in your case, i.e. how hardened the servers are against someone getting root access and reading other users’ tickets.
I would have to open a flow between servers and KDC port 88 on our firewall.
That shouldn’t be an issue. (In fact, I don’t understand why that isn’t already open.)
I’d rather avoid NOPASSWD inside sudoers, but if members of group sudo authenticate via kerberos, are there any security concerns about putting NOPASSWD inside sudoers for that group?
What you’re planning already functions like NOPASSWD – the idea is that if pam_sss_gssapi succeeds, it will immediately return out of PAM without reaching the "ask for password" pam_unix module at all.
However, if you enabled NOPASSWD, it would bypass the Kerberos authentication as well. The reason is that Sudo doesn’t prompt for password explicitly – it only calls PAM to authenticate the user, and the NOPASSWD flag actually means "no PAM authentication". (It does not mean "no password" as such; it just happens that the standard PAM module (pam_unix) asks for a password.) But if you enable NOPASSWD, then sudo will never call PAM for auth, therefore skipping both pam_unix and pam_sss_gss.
Windows Kerberos uses PAC to forward groups membership. Do you have any idea why is that feature not implemented in MIT Kerberos?
MIT Kerberos, being the "original" Kerberos distribution, continues to follow its original design where authorization (access control) is explicitly not part of Kerberos functionality – it is purely an authentication system.
I mean NSS from Linux has to poll the LDAP frequently to feed its databases about the users and groups.
It doesn’t poll LDAP at any frequency; it queries LDAP only when a user is "logged in" – not significantly different from Windows.