On 08/07/2012 01:23 PM, Matt Garman wrote: > [root@lnxsvr11 ~]# grep 192.168.187.67 /etc/hosts > 192.168.187.67 lnxsvr11.mydomain.com lnxsvr11 > [root@lnxsvr11 ~]# grep "lnxsvr11\." /etc/hosts > 192.168.187.67 lnxsvr11.mydomain.com lnxsvr11 > [root@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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
