Home / server / Questions / 560413
In Process
drewrockshard
Asked: 2013-12-11 07:23:01 +0800 CST

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

  • 772

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 [email protected]
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
networking

3 Answers

  1. 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
    • 1

  2. The symptoms suggest that kerberos is broken for one client. If you ssh via IP then kerberos is usually not involved.

    The most common cause of kerberos broken for one client is that the time is out of sync on that client. Kerberos requires that all hosts involved have their system clocks roughly in sync. 

    /bin/date

    on both client and server should be within seconds of each other.

    • 1

  3. So thanks to all they gave me some recommendations. I ended up finding the issue, however. I had written a simple expect script that basically copies my SSH key over to each server, and it knows what the servers are by a simple file.

    So, I saw no error in anything, but for this one host, it appears that I had a "known_hosts" entry that conflicted with my SSH key, and it basically would just drop my connection. I deleted the known_hosts file (all I really had to do was remove the one item in known_hosts) and then retried my connection - and was granted access.

    Simple fix, but the errors weren't helping or pointing me to an obvious fix.

    Thanks!

    • 1