On Wed, 27 Apr 2011, Greg Hudson wrote: > I'm not entirely sure what's going wrong, but I can explain this part, I > think. Solaris Kerberos defaults to not doing reverse canonicalization > of hosts, and OSX may do so as well.
Does this happen on Solaris even if the Kerberos used is MIT Kerberos? This particular solaris client is using OpenSSH 5.0p1 w/gssapi-keyex that was statically linked with MIT Kerberos 1.6.3. >> There are "host" principals for both hostnames in /etc/krb5.keytab and >> GSSAPIStrictAcceptorCheck is set to "no" in sshd_config. > > I would expect the authentication exchange to work regardless of which > service principal the client chooses, in this configuration. If you can > get the sshd -d output on the server, there might be some enlightening > information there. I have tried sshd -e -ddd, but don't see any clues... at least nothing that helps me. >From the server-side it just seems to close the connection. Here's the last bit of the debug output from a failed connection: ... debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 51 used once, disabling now debug3: mm_request_receive entering Connection closed by 1.2.3.4 And here's that same section of debug output from a successful connection: ... debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 51 used once, disabling now debug3: mm_request_receive entering debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done ... > It's conceivable that the client is performing the canonicalization step > twice and getting different answers, but I don't know what the details > of that scenario would be. This is what I've suspected, but not sure how to verify it. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
