ssh gssapi-with-mic and "Key table entry not found"

[Greg Hudson]

On 08/07/2012 01:23 PM, Matt Garman wrote:
>     [root at lnxsvr11 ~]# grep 192.168.187.67 /etc/hosts
>     192.168.187.67     lnxsvr11.mydomain.com      lnxsvr11
>     [root at lnxsvr11 ~]# grep "lnxsvr11\." /etc/hosts
>     192.168.187.67     lnxsvr11.mydomain.com      lnxsvr11
>     [root at lnxsvr11 ~]# grep "lnxsvr11$" /etc/hosts
>     192.168.187.67     lnxsvr11.mydomain.com      lnxsvr11

I didn't see a smoking gun in the output you sent, but here are some
pointers.  You need the following three things to match:

  1. The canonicalization of lnxsvr11 on the client
  2. The canonicalization of the result of gethostname() on the server
  3. The hostname in the keytab entry

By default, canonicalization is done using getaddrinfo() forward
resolution and then getnameinfo() reverse resolution.  Depending on the
Kerberos version, canonicalization may or may not be restricted to IPv4
lookups.  (2) can be ignored if your sshd has sxw's patches using the
"GSSAPIStrictAcceptorCheck no" option, but I don't think CentOS 5.7's
build of sshd has those patches.

You can see what (1) is by running klist on the client after attempting
the ssh.  That would be useful information for debugging this problem.

You should be able to see what (2) is on the server by getting tickets
for somebody and then running "kvno -S host lnxsvr11" and seeing what
principal that gets (or tries to get) server tickets for.  (There are
easier ways to do this with more recent versions of MIT Kerberos--in 1.9
or later, it would appear in the sshd debug output, for instance.  But
CentOS only has krb5 1.6.1 as far as I can tell.)

It's of course easy to see what (3) is, and you've already provided that.