Multiple hostnames with same IP address (DNS A record)

[petesea@bigfoot.com]

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.