Problem with kerberos and ssh.

Douglas E. Engert deengert at
Wed Mar 1 16:03:54 EST 2006

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
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 
>>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/ 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/ 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/ 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
>>=== 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
>>=== server log ===
>>debug1: userauth-request for user vatester service ssh-connection method 
>>debug1: attempt 1 failures 1
>>debug2: input_userauth_request: try method gssapi-with-mic
>>Postponed gssapi-with-mic for vatester from 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


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

More information about the Kerberos mailing list