SSH weirdness
I've configured a new container/zone on Solaris 10 (Sparc) and I'm using Centrify for LDAP authentication to AD. My ssh client is as follows
Sun_SSH_1.1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
I'm seeing some strange behavior from ssh. When I ssh onto the new zone to myself (non-root user) either from elsewhere or from the zone itself, I get the following error:
Server had a GSS-API error; the connection will close (851968/0):
Unspecified GSS failure. Minor code may provide more information
No error
Use the GssKeyEx option to disable GSS-API key exchange and try again.
Disconnecting: The server had a GSS-API error during GSS-API protected SSHv2 key exchange
This is accompanied by the following error in /var/adm/messages:
sshd[15808]: [ID 800047 auth.crit] fatal: accept_ctx died
The problem does NOT present if I ssh to the zone from root OR if I use the host's IP address instead of hostname. I have no problem ssh'ing away from the zone - only when inbound.
Here's the debug output from ssh -vvv:
Sun_SSH_1.1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to balloonv1 [10.38.35.100] port 22.
debug1: Connection established.
debug1: identity file /users/cmorgan/.ssh/identity type -1
debug1: identity file /users/cmorgan/.ssh/id_rsa type -1
debug1: identity file /users/cmorgan/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.1
debug1: match: Sun_SSH_1.1.1 pat Sun_SSH_1.1.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.1
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-AU
debug2: kex_parse_kexinit: en-AU
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: ssh_gssapi_init_ctx(706a8, balloonv1, 0, 0, ffbff714)
debug3: ssh_gssapi_import_name: snprintf() returned 14, expected 15
debug2: GSS-API Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
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,null
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-AU
debug2: kex_parse_kexinit: en-AU
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
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-AU,en-NZ,i-default
debug2: kex_parse_kexinit: en-AU,en-NZ,i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: en-AU,en-NZ,i-default
debug1: Peer sent proposed langtags, stoc: en-AU,en-NZ,i-default
debug1: We proposed langtags, ctos: en-AU
debug1: We proposed langtags, stoc: en-AU
debug1: Negotiated lang: en-AU
debug1: dh_gen_key: priv key bits set: 119/256
debug1: bits set: 497/1024
debug1: Calling gss_init_sec_context
debug1: ssh_gssapi_init_ctx(d2458, balloonv1, 0, 0, ffbff7d4)
debug3: ssh_gssapi_import_name: snprintf() returned 14, expected 15
debug1: Remote: Negotiated main locale: en_AU.UTF-8
debug1: Remote: Negotiated messages locale: en_AU.UTF-8
debug1: Received KEXGSS_HOSTKEY
Server had a GSS-API error; the connection will close (851968/0):
Unspecified GSS failure. Minor code may provide more information
No error
Use the GssKeyEx option to disable GSS-API key exchange and try again.
Disconnecting: The server had a GSS-API error during GSS-API protected SSHv2 key exchange
debug1: Calling cleanup 0x348a4(0x0)
Curiously, if I run kdestroy, I can then ssh sucessfully but only for that login session.
I'm not familiar with kerberos. What's happening here?
- CDM
