[9708] in athena10
[Debathena] #1195: Kerberized ssh to athena.dialup.mit.edu fails
daemon@ATHENA.MIT.EDU (Debathena Trac)
Thu Aug 2 14:33:29 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: kchen@MIT.EDU
Date: Thu, 02 Aug 2012 18:33:26 -0000
Reply-To:
Message-ID: <041.63dd0a8f1c3d8d4b6259d95812b677e0@mit.edu>
Content-Transfer-Encoding: 8bit
#1195: Kerberized ssh to athena.dialup.mit.edu fails when keytab obtained doesn't
match ssh machine
--------------------------------+-----------------------------------
Reporter: kchen | Owner:
Type: defect | Status: new
Priority: normal | Milestone: The Distant Future
Component: development | Keywords:
Fixed in version: | Upstream bug:
--------------------------------+-----------------------------------
(geofft's writeup on debathena@mit.edu on April 17, 2012)
Comcast's residential DNS IPs (75.75.75.75 and 75.75.76.76) are anycast
addresses for muliple machines, which means that when looking up
*.dialup.mit.edu, which is load-balanced at the DNS level, there's no
guarantee that two successive client lookups (from a stub resolver) will
hit the same server, and thus are more likely than not to give you two
different results, because the first DNS server you hit is happily caching
your result while you talk to the second DNS server.
This means that if you open an SSH connection to athena.dialup.mit.edu and
ssh then asks the Kerberos libraries to get tickets for
athena.dialup.mit.edu, the Kerberos libraries are likely to canonicalize
the name into another server than the existing SSH connection and give you
a service ticket for a the wrong dialup, leading to various random but
probable failures setting up a Kerberos connection.
Combined with the underlying issue behind Trac #315 where a failed keyex
aborts the connection, as opposed to falling back to another keyex method
(like checking the server's RSA key), this manifests as athena.dialup
giving "Connection closed" messages more often than not from a Debathena
box on a Comcast residential connection if the user has active tickets.
I recommend we give some thought to one or more of
1) giving up on GSSAPIKeyExchange (#315 is almost excuse enough, but
combining it with #787 and this issue makes it something of a real
problem), at least until we can teach SSH to do keyex fallback
2) changing athena.dialup from DNS-level load balancing to IP-level, by
assigning a distinct IP to athena.dialup and having every athena.dialup
host include the host/athena.dialup.mit.edu key in its keytab in
addition to its own (and turning off the GSSAPIStrictAcceptorCheck);
this is basically the configuration of the scripts.mit.edu pool, except
that ssh connections aren't actually load-balanced.
This would also have some UI benefits for non-GSSAPI users, since they
would only get a host key prompt/warning for the single IP once.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1195>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
