Help wanted with GSSAPI in OpenSSH

[Nico Williams]

On Thu, Dec 11, 2025 at 11:23:45AM +1100, Damien Miller wrote:
> This is a request for assistance in maintaining the GSSAPI code in
> OpenSSH.

Hi.

> None of the maintainers have much experience with GSSAPI and none of
> us use it in our usual use of OpenSSH. We don’t have *any* testing of
> GSSAPI features in our unit test suite, let alone fuzzer coverage.
> 
> GSSAPI code is complex and largely pre-authentication, so mistakes there
> have the potential to yield serious vulnerabilities. Because we really
> don’t want to introduce such a bug, myself and the other maintainers are
> very hesitant to make or merge changes in this area.

GSS-API can be run w/ only the privilege to read the acceptor
credentials (typically a Kerberos 'keytab'), though handling of
delegated credentials can get tricky (but with the gss_store_cred*()
extensions it's manageable).  So as long as you can arrange for that you
can 'privsep' the GSS-calling code just fine.  RedHat has a "gssd" that
you could perhaps use in this way, but that might not be so portable
(OTOH, I got them to use a non-infectious licence for it, or at least
for the ONC RPC definitions).

> This isn’t a sustainable situation - a whole area of preauth code that
> is not adequately tested or maintained is at the same time an accident
> waiting to happen and a case where we’re not serving our users properly.
> 
> There are two paths out of this situation: either 1) we deprecate and
> ultimately remove the GSSAPI code as unmaintained or 2) we greatly
> improve the testing and maintenance of the code.

I have (and in principle still do) maintain GSS-KEX patches w/
gssapi-keyex userauth support, which I understand you'll never adopt.
Viktor Dukhovni and I contributed client-side patches for that to PuTTY,
and those patches were integrated.  In particular those patches enable
to client to delegate fresh credentials before the previously delegated
ones expire, thus keeping the user's server-side session supplied with
fresh credentials.  But...

$WORK is moving away from all that as much as possible because as SSHv2
implementations have become very common GSS support has become harder to
come by and we cannot patch all the things -- indeed, we're even moving
away from Kerberos.  Instead of delegating credentials we'll end up just
arranging for credentials (of all kinds) to be available for each user
on the very few hosts they are allowed to login to interactively
(typically one or two, typically single-user systems).  Then for
authentication in SSHv2 we need only use public keys (my preference
would be PKIX certificates, but I understand that is not your preference
so we'll probably end up with OpenSSH-style certificates).

BTW, suppose you had a really nice ASN.1 compiler and DER/BER library
you could use, with a suitable license, that you could fuzz endlessly,
maybe even privesep the codecs [if the codec used arenas and relative
pointers you could transfer entire arenas over IPC].  Would such a thing
make you more amenable to supporting x.509/PKIX?  I ask because a)
Heimdal has such a thing, b) Heimdal has an x.509/PKIX implementation
independent of OpenSSL's, with a very nice API.

> There is a substantial user community who depend on GSSAPI out there, so
> I’m hoping the second path is viable.
> 
> Our most pressing need is testing - we have no regression tests that
> exercise the common GSSAPI authentication and authorisation flows. Is
> anyone willing to help write such tests? If so, please let us know and
> we can talk about next steps.

I'll see what I can do.  I need to get permission at $WORK to make such
contributions, and I need time.  What are your timelines?

Nico
--