Use gss_userok() instead of krb5_kuserok().

[jas4711]

Hi

I'm exploring if it is possible to drop the run-time linking of libkrb5 for OpenSSH and instead link to libgssglue -- https://gitlab.com/gsasl/libgssglue -- which is intended as a thin generic GSS-API wrapper that dlopen() MIT Kerberos V5 or Heimdal depending on sysadmin preferences, or does nothing if Kerberos is not installed on the system. This would allow people to avoid the Kerberos dependency for OpenSSH, but still allow this functionality (via libgssglue) for those people who are interested in Kerberos.

For this to work, OpenSSH shouldn't use Kerberos-specific libraries, header files or APIs, but purely call standardized GSS-API functions. Fortunately this seems to almost already be the case, with two exceptions that have been isolated into gss-serv-krb5.c:

• ssh_gssapi_krb5_userok: This function uses krb5_userok(). Solaris has always had gss_userok(), and I believe MIT Kerberos V5, Heimdal and Apple Kerberos (which effectively is Heimdal as far as I remember) has support for gss_userok() for 10+ years.

• ssh_gssapi_krb5_storecreds: This forwards Kerberos credentials to the receiving system. I believe GSS-API supports this via RFC 5588 -- https://datatracker.ietf.org/doc/html/rfc5588 -- and the gss_store_cred() should offer this functionality.

This pull request only fixes the first of these, and is offered here to get discussion, testing and code review started. It builds on my system, but little further testing. What seems to be lacking to have confidence in patches like this is a regression test framework that performs a Kerberos V5 authenticated SSH login. Ideally this should be part of the GitHub actions. Setting it up a local KDC in userspace isn't that hard -- I've done it to self-test libgsasl's GSSAPI against Dovecot in https://gitlab.com/gsasl/gsasl/-/blob/master/tests/gsasl-dovecot-gssapi.sh -- however I'm not that familiar with GitHub actions or the OpenSSH regression framework to add this myself. Is someone interested in collaborating on adding that? I think one job should setup a KDC, acquire a server keytab for sshd and a user ticket and perform a krb5 ssh login.

While libgssglue has still some mileage to go (for example, it should support gss_userok :-)), I think that regardless of that approach's merits, OpenSSH should use standardized GSS-API interfaces instead of custom krb5_*() APIs. So this patch does nothing related to libgssglue at all, but merely try to move OpenSSH up to modern GSS-API usage first. It will then later be possible to offer a patch that would link to libgssglue instead of libkrb5.

Thoughts?

[djmdjm]

This looks reasonable (modulo tabs vs spaces formatting), but I'm really not a GSSAPI or KRB5 expert. I think the best way to proceed is to find someone who knows more about these APIs to take a look and chime in here.

[abbra]

I can do a review of this.

I am working on adding authentication indicators support and it touches pretty much the same code. This is done with RFC 6680 GSSAPI name attributes extensions ( gss_get_name_attribute() function) that are supported for quite some time by both MIT Kerberos and Heimdal but libgssglue does not have support for it. It is not a big deal to add that but I'd like to see that before we'd get to switch to libgssglue.

I think it makes sense to keep the use of the mech callback to allow more complex checks in it. Linux distributions largely share same patches around this area that add a logic to support .k5login and .k5user for ksu compatibility. It would allow to use GSSAPI by default but avoid patching in the core in gss-serv.c. From those patches point of view use of libgssglue is transparent: it is pretty much GSSAPI, after all.

@jas4711 can you add RFC 6680 support to libgssglue? Feel free to add me as a reviewer (same nickname on gitlab) if you need some help.