Problem with kerberos and ssh.

[Eric]

	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.


Eric wrote:
> 
> I am trying to get kerberos working in a small test environment.  I am 
> using a Windows Server 2003 as a KDC, and two Linux boxes as clients. 
> The two linux boxes are Suse 10 and are virtual clones of each other.
> 
> I followed instructions I found on the web and was able to configure the 
> Linux boxes to be Kerberos clients - I am able to log into both of them 
> and use kerberos for authentication.
> 
> To take it to the next level, I downloaded and built openssh-4.3p2 on 
> both Linux boxes, and then I try and connect from one machine to the 
> other.  It looks like the connection is virtually complete, and then it
> finds something it doesn't like and then tears the whole thing down.
> 
> Right now I am at a bit of a loss - I don't know what the client 
> credentials are that the thing is talking about, nor do I know what type 
> of invalid name might have been supplied.  In particular, I don't know 
> whether this is a Kerberos configuration issue, or a ssh issue.
> 
> The client does seem to be able to get a host ticket for the remote 
> machine:
> 
> vatester at babel-vm-suse:/home/eric/bin2> klist -e
> Ticket cache: FILE:/tmp/krb5cc_1006
> Default principal: vatester at VADEV.COM
> 
> Valid starting     Expires            Service principal
> 02/25/06 08:27:21  02/25/06 18:27:21  krbtgt/VADEV.COM at VADEV.COM
>         renew until 02/26/06 08:27:21, Etype (skey, tkt): DES cbc mode 
> with RSA-MD5, DES cbc mode with RSA-MD5
> 02/25/06 08:27:45  02/25/06 18:27:21 
> host/babel-vm-suse2.vadev.com at VADEV.COM
>         renew until 02/26/06 08:27:21, Etype (skey, tkt): DES cbc mode 
> with RSA-MD5, DES cbc mode with RSA-MD5
> 
> === the host keytabs were generated on w2k3 with the command line ===
> ktpass /out vadev.keytab /mapuser babel-vm-suse /princ 
> host/babel-vm-suse.vadev.com at VADEV.COM /pass welcome /crypto DES-CBC-MD5 
> /ptype KRB5_NT_PRINCIPAL /mapOp set +desonly /target vadevdc
> 
> ktpass /out vadev2.keytab /mapuser babel-vm-suse2 /princ 
> host/babel-vm-suse2.vadev.com at VADEV.COM /pass welcome /crypto 
> DES-CBC-MD5 /ptype KRB5_NT_PRINCIPAL /mapOp set +desonly /target vadevdc
> 
> === client commandline ===
> ssh -v -v -v -o GSSAPIAuthentication=yes -p 16 babel-vm-suse2.vadev.com
> 
> === server commandline ===
> sshd  -e -d -d -d -D -r -p 16 -f /home/eric/bin2/sshd_config
> 
> === server config ===
> # Kerberos options
> KerberosAuthentication yes
> #KerberosOrLocalPasswd yes
> #KerberosTicketCleanup yes
> #KerberosGetAFSToken no
> 
> # GSSAPI options
> GSSAPIAuthentication yes
> #GSSAPICleanupCredentials yes
> 
> === client log ===
> debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
> debug3: authmethod_lookup gssapi-with-mic
> debug3: remaining preferred: publickey,keyboard-interactive,password
> debug3: authmethod_is_enabled gssapi-with-mic
> debug1: Next authentication method: gssapi-with-mic
> debug2: we sent a gssapi-with-mic packet, wait for reply
> Connection closed by 10.18.3.53
> 
> === server log ===
> debug1: userauth-request for user vatester service ssh-connection method 
> gssapi-with-mic
> debug1: attempt 1 failures 1
> debug2: input_userauth_request: try method gssapi-with-mic
> Postponed gssapi-with-mic for vatester from 10.18.3.52 port 1960 ssh2
> debug1: Got no client credentials
> debug1: An invalid name was supplied
> A parameter was malformed
> Validation error
> 
> Couldn't convert client name
> debug1: do_cleanup