Ssh – Weird SSH Issue – Single host not allowing me to login via name

domain-name-systemnetworkingpublic-keyssh

Can anyone explain this, because I have done everything from regenerating keys, to "leaving" and rejoining the domain (Centrify) for an SSH host that I can't seem to get to by a single client. All other clients are able to access this host, except one. Weirdly, though, I can SSH to the host from the client if I use the IP address:

$ ssh ddecker@host
Connection closed by 10.0.0.250
$ ssh ddecker@10.0.0.250
Password:
[ddecker@host ~]$

The only thing I have on this is inside /var/log/messages on the host, I get the following when trying to use the hostname:

fatal: accept_ctx died [preauth]

I've tried removing /etc/krb5.keytab, but then Centrify doesn't start; so I reverted it back. Really not sure what is going on as to why all other clients can connect by name and this since client can only connect via IP.

UPDATE #1:

Here is the output of ssh -v ddecker@host:

debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to host [10.0.0.250] port 22.
debug1: Connection established.
debug1: identity file /home/ddecker/.ssh/id_rsa type 1
debug1: identity file /home/ddecker/.ssh/id_rsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_dsa type -1
debug1: identity file /home/ddecker/.ssh/id_dsa-cert type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa type -1
debug1: identity file /home/ddecker/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: Offering GSSAPI proposal: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Doing group exchange

debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by 10.0.0.250

Best Answer

Debugging AD/Kerberos Centrify is always annoying.

You might want to try to enable Centrify debugging on your server with /usr/share/centrifydc/bin/addebug on. Be aware that this can create very large log files, and potentially lead to full volumes if left enabled too long.

Check the SPN's and the KVNO's

Get list of principles and KVNO's from local keytab on your server. This may require that the Kerberos client utilities RPM package is installed on a Linux server (yum install krb5-workstation).

klist -kte

Compare that with the Kerberos KVNO as determined by your AD. From another Centrify enebales Linux system: (Requires active Kerberos login session initiate with “kinit ", check with klist if you have a valid kerberos ticket granting ticket)) Best to do his from another host then the one experiencing problems. SSH uses the hosts principal.

kvno host/hostname
kvno host/hostname.domain.name

If the two commands above return different KVNO's then found with klist for the same principle, then typically the local keytab file on the UNIX server requires a reset. Resetting the local keytab when it is not in sync with the KDC in AD is done from the commandline of the host concerned and requires root priviliges.

adkeytab -r -u <username>

or use the local computer account credentials instead of the priviliged AD user above 

adkeytab -r -m
Related Topic