Disabling host key checking on LAN

[Nico Kadel-Garcia]

On Mon, Aug 31, 2015 at 9:02 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
> On 30 August 2015 at 18:53, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>>
>> On Sun, Aug 30, 2015 at 6:57 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
>> > those were my thoughts, exacly, except that I was thinking about using "dig
>> > +short HOST | ..." which has the cleanest output of all.
>>
>> It can get a bit confusing with
>> round-robin DNS, which can give multiple responses.
>
>
> Care to illustrate your use case?

For confusion without "round-robin DNS"? Sure.

#  dig +short www.google.com
63.117.14.21
63.117.14.23
63.117.14.25
63.117.14.22
63.117.14.24
63.117.14.26
63.117.14.20
63.117.14.27

That's an unordered list of not-necessarily identical targets, it's
quite dynamic, and the exposed IP addresses *do not necessarily have
the same SSH key*. Moreover, the resolution of the specific IP
addresses when establishing a new connection is not really
"round-robin". working its way through a particular order. The
"round-robin" is typically a common, but subtly mistaken one. It's
actually multiple A records, and that is the local libc library's
problem to resolve, and the results can be.... unpredictable.

A more powerful specific local example is Samba or Active Directory
servers for a particular domain. The DNS domain for thei "EXAMPLE"
Active Directory might be "example.com". The AD or Samba servers, both
active and failover, will publish A records for themselves as
"example.com", "_kerberos.tcp.example.com", and other multiple A
records, no matter if they have individual host names of
"samba1.example.com" and "samba2.example.com".

Should those multiple AD servers have identical SSH keys, simply to
prevent confusion if I look up "example.com" and need to talk to it as
an admin? Or do I personally have to keep track, somehow, of which
server is which and talk to its individual name, even if all I really
want to do is set up a shared configuration, or even log into it to do
DNS zone transfers on localhost to get configuration information for
the entire domain, and I *have* the designated root SSH keys for
exactly such access?

> I am having difficulties imagining it:
> 1. If you are managing particular host, you connect to its IP directly
> (possibly via DNS entry).
> 2. If that DNS entry represents a service that has a load-balanced IP
> list, you should not be connecting to arbitrary host in that list, but
> use dedicated IP of particular server in that list, or am I missing
> something here?

You're missing that what people *should* do is often not trivially
available to the SSH client. There are even poorly configured load
balancer environments where the load balancer exposed entry was the
only to get at the SSH service directly from outside the local network
That drove me *nuts* for a particular svn+ssh environment some years
back, I really wanted to hit the admin who did that with a brick
because it was an intermittent problem. We won't even *discuss* the
problems caused because the svn+ssh setup was already split-brain with
write privileges on both servers.

> Additional point:
> If your environment gets complicated enough, it probably justifies
> usage of ProxyCommand directive with reference to dedicated
> script/program that does the necessary plumbing (technical and
> policy-wise) to set up your connection.
>
> b.

Which I'd have to set up manually for every remote host target, and
would have to propagate or configure on any workstation I happen to
work from. Let's see, hand-tuning .ssh/config everywhere, or just
throwing out hostkey based SSH verification so I don't have to spend
time confirming new keys and can get on with my work.... I know which
is the better security option, but I also know which is the more
common "stop bothering me about this!" option.