Problem with kerberos and ssh.

[Jeffrey Altman]

Eric wrote:
> 
>     I have reached the conclusion that this is an ssh bug and not a
> kerberos bug or configuration problem.
> 
>     Essentially the problem was that ssh is calling
> 
>    ctx->major = gss_accept_sec_context(&ctx->minor,
>        &ctx->context, ctx->creds, recv_tok,
>        GSS_C_NO_CHANNEL_BINDINGS, &ctx->client, &mech,
>        send_tok, flags, NULL, &ctx->client_creds);
> 
> and saving off ctx->client for later use.  Under the hood, ctx->client
> is simply a gss_union_name_t.
> 
> Later on, ssh calls
> 
>         if ((ctx->major = gss_export_name(&ctx->minor, ctx->client,
>             &ename))) {
>                 ssh_gssapi_error(ctx);
>                 return (ctx->major);
>         }
> 
> Here ctx->client is passed in and 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.
> 
> I honestly have no clue how this could have ever have worked - my guess
> is that at one point in the past libgssapi didn't have the
> gss_union_name_t, and just used krb5_principal as a return parameter
> from gss_accept_sec_context().  Anyways, I hacked the thing and got it
> working which is good enough for me now - I will post this information
> over at the openssh mailing list to see what they think.

What is gss_union_name_t defined as?   This is not a GSS type.

gss_accept_sec_context() exports a gss_name_t object and
gss_export_name() takes a gss_name_t as input.  gss_name_t when produced
by a krb5 gss mechanism will be a krb5_principal.  However, gss_name_t
is not required be a krb5_principal.

Jeffrey Altman