Bug in Kerberos support for openssh.

[sxw at inf.ed.ac.uk]

[ cross-posted both to openssh-unix-dev and kerberos at mit.edu as this
   question has been asked on both lists ]

The first and most important point to note here is that the problem you're 
seeing isn't a bug in OpenSSH - it's a problem with the libraries that 
your vendor is shipping, and in particular with the libgssapi package.

On Mon, 27 Feb 2006, Eric Youngdale wrote
> I spent some time in the debugger, and found that essentially the
> problem was that ssh is calling
>
>   ctx->major = gss_accept_sec_context(&ctx->minor,
> Later on (not much further later), ssh calls
>
>        if ((ctx->major = gss_export_name(&ctx->minor, ctx->client,
>
> Here ctx->client is passed in but gss_export_name assumes that the input
> name is a krb5_principal.  Not surprisingly, the datatype mismatch
> causes the call to fail.  Could have caused it to crash, I suppose -
> that would have been a much clearer indication of what the trouble was.

GSSAPI is an IETF standard. If your GSSAPI library doesn't allow 
gss_export_name to be called with the client name returned by 
gss_accept_sec_context then it is broken. The type of the client name 
is, as others have noted on the Kerberos mailing list, opaque. An 
implementation can chose to make this whatever it likes, as long as that
decision is consistent across every call.

The OpenSSH code has been tested with (to my knowledge) GSSAPI 
implementations from MIT, Heimdal and Globus, and works correctly with all 
of these.

SuSe 10 ships with a library called 'libgssapi', which isn't a Kerberos 
GSSAPI library at all (the Kerberos GSSAPI library from the MIT code is 
called libgssapi_krb5.so). It's a version of the 'mechglue' code which, I 
believe, CITI have packaged up to work with NFSv4. It acts as a 'shim' layer,
allowing multiple different GSSAPI libraries to be used by the one 
application.

Unfortunately this code has issues that are causing problems for a number 
of people trying to do GSSAPI on SuSE 10. Firstly, it calls exit() when it 
encounters problems - not particular great behaviour from a shared 
library. I first encountered this with Thunderbird's Kerberos support - 
both Thunderbird and Firefox now explicitly check for this library and 
don't use it if found.

Secondly, as you've noted, its support for calling 'export_name' is 
broken. In fact, the version of the library that I have to hand doesn't 
even support export_name - so I suspect that you're falling back to using 
the native export_name provided by libgssapi_krb5, although I'm not 
familiar enough with the behaviour of Linux's linker to work out how.

The short answer is - don't build OpenSSH against libgssapi - build it 
against the GSSAPI library (libgssapi_krb5) which ships with MIT Kerberos. 
File a bug with your vendor about the fact that they're shipping a broken 
GSSAPI library.

I'll drop Kevin Coffman at UMICH a mail about this too.

Cheers,

Simon.