[33348] in Kerberos
Re: Multiple hostnames with same IP address (DNS A record)
daemon@ATHENA.MIT.EDU (petesea@bigfoot.com)
Wed Apr 27 15:24:49 2011
Date: Wed, 27 Apr 2011 12:24:38 -0700 (PDT)
From: petesea@bigfoot.com
To: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <1303928647.2493.76.camel@t410>
Message-ID: <alpine.OSX.2.00.1104271129340.782@nikto-air>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
