Problem with kerberos and ssh.

[Douglas E. Engert]

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:
>>
>>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
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444