Problems connecting to Solaris 10 SSH from GSSAPI-keyex patchedOpenssh 4.2p1

[Nicolas Williams]

On Mon, Sep 26, 2005 at 11:15:51AM -0400, Rob See wrote:
> Hi,

The folks who run this list will probably tell you to send this kind of
post to kerberos at mit.edu instead of krbdev at mit.edu.

> 	I'm having problems connecting to Solaris 10 SSH from Openssh 4.2p1 
> patched with Simon Wilkinson's gssapi-keyex patch or the Globus GSSAPI 
> patch. Openssh is compiled against kerberos 1.4.2. The connections fail 
> if I have a current kerberos ticket. The stock Openssh connects ok, but 
> the ticket doesn't get passed from one machine to another. Below are the 
> Openssh Client logs and the Solaris SSH Server logs. Does anyone have 
> any suggestions on how I might get this working  ?

See below.

> OpenSSH_4.1p1 NCSA_GSSAPI_20050526 KRB5, OpenSSL 0.9.7a Feb 19 2003
...
> debug2: kex_parse_kexinit: 
> gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
...
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: 
> gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

So GSS keyex using the Kerberos V mechanism is negotiated.

...
> debug1: Calling gss_init_sec_context
> debug1: Received KEXGSS_HOSTKEY
> debug1: Calling gss_init_sec_context
> debug1: A token was invalid
> No error
> 
> gss_init_context failed

This seems odd -- your client got a ticket, tokens were exchanged, but
there was a problem with the token sent back by the server.  It's not
likely to have been corrupted (certainly not on the wire), so it must be
something else.

> Server log:
> debug1: sshd version Sun_SSH_1.1
...
> debug1: Wait SSH2_MSG_GSSAPI_INIT
> debug1: gss_complete

The server thinks everything went fine and sent back a reply token.

> debug1: dh_gen_key: priv key bits set: 121/256
> debug1: bits set: 525/1024
> debug1: bits set: 530/1024
> debug2: kex_derive_keys
> debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
> debug1: newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> Write failed: Broken pipe

Then the client went away.

Is it possible that the client is choking on the KEXGSS_HOSTKEY message?

I think you might want to ask Simon Wilkinson.

Nico
--