openssh-portable
openssh-portable copied to clipboard
openssh
support authentication indicators in GSSAPI
RFC 6680 defines a set of GSSAPI extensions to handle attributes associated with the GSSAPI names. MIT Kerberos and FreeIPA use name attributes to add information about pre-authentication methods used to acquire the initial Kerberos ticket. The attribute 'auth-indicators' may contain list of strings that KDC has associated with the ticket issuance process.
Use authentication indicators to authorise or deny access to SSH server. GSSAPIIndicators setting allows to specify a list of possible indicators that a Kerberos ticket presented must or must not contain. More details on the syntax are provided in sshd_config(5) man page.
Fixes: https://bugzilla.mindrot.org/show_bug.cgi?id=2696
All failures seem to be about penalty.sh dependency of a t-exec which is unrelated to the PR changes, it seems.
This looks pretty reasonable but I don't think any of the active developers have the GSSAPI knowledge to review the GSSAPI bits of this change. We'll have to find someone with more experience to look at it.
@djmdjm I am one of FreeIPA, SSSD, and Samba developers and contribute to MIT Kerberos as well. This code is based on my indicators work for SSSD's pam_sss_gss which we have in production since 2021.
If you want more external eyes, I can ask my fellow Red Hat colleagues who maintain OpenSSH and wrote GSSAPI code in past too.
I'm working on libssh, MIT Kerberos and Samba. I can review the GSSAPI bits.
I updated the code to follow recent discussions. Let me know whether this is all fine for merge.
I have recorded a demo here: https://www.youtube.com/watch?v=OauHdZYKGKk. This demo shows the use of GSSAPIIndicators option in a Match block to constrain two users (unenforced-user and enforced-user) to authenticate with GSSAPI when their initial Kerberos tickets were obtained in a particular way. In this demo we just deny any ticket that was not obtained with OTP or a smartcard-based pre-authentication mechanism. Since FreeIPA associated a hardened indicator with SPAKE pre-authentication method (used for password-based auth), we also reject hardened indicator.
In the demo, first we attempt to access as unenforced-user, with a ticket that contains hardened indicator. Then we access as enforced-user, with a ticket that contains otp indicator. In the first case we fail and system logs show that clearly. In the second case we succeed. Again, logs demonstrate that a particular indicator was inspected and accepted.
I have been on vacation for past few weeks so may be I missed something... @djmdjm Is there anything else preventing a further review and inclusion of the GSSAPI authentication indicators work?
This code looks good to me after the changes I've requested are done and we are interested in having it upstream. @djmdjm could you please look at it if time permits?
