As many others have pointed out, it looks like you are trying to use a buggy version of a gssapi mechglue. There are versions that do actually work, such as the UIUC http://grid.ncsa.uiuc.edu/gssapi-mechglue/ or the Solaris 10 version.
The mechglue version that has comes with the MIT Kerberos for many releases has not received much attention, and I have never heard of it being tested with any other GSSAPI. (Thus the UIUC version) 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. > > > 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: >> >>[EMAIL PROTECTED]:/home/eric/bin2> klist -e >>Ticket cache: FILE:/tmp/krb5cc_1006 >>Default principal: [EMAIL PROTECTED] >> >>Valid starting Expires Service principal >>02/25/06 08:27:21 02/25/06 18:27:21 krbtgt/[EMAIL PROTECTED] >> 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/[EMAIL PROTECTED] >> 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/[EMAIL PROTECTED] /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/[EMAIL PROTECTED] /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 > > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos