openssh unix dev - Aug 2015 - Disabling host key checking on LAN

On Fri, Aug 28, 2015 at 8:48 AM, Bostjan Skufca <bostjan at a2o.si>
wrote:
> On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote:
>> Yeah, it's unfortunately quite difficult to implement address
matching
>> in ~/.ssh/config because of the interplay of Host matching, Hostname
>> directives, hostname canonicalisation*, proxy commands, hosts having
>> multiple addresses, IPv4/IPv6 and when the addresses are actually
>> resolved and available to the parser.
>>
>> I've not figured out a clean way to do it that isn't also
complex and
>> probably fragile to implement.
>
> If we disregard the "complex and probably fragile" part, what is
the
> "clean way" you are talking about?
> Do you have some sort of RFC written down somewhere?
The interplays between DNS and multiple formats for the same target
SSH server makes such an RFC a nightmare in outsmarting all the local
settings. In complex environments, I'm afraid that "known_hosts"
is
often an active detriment to stable operation, especially because
there is *no* published tool for "scrub the old rejected line and
accept the new one*. It's most clear when a new server on the same IP
address replaces an old host but uses new SSH host keys.

In environments where critical server hostnames and IP addresses are
not tied to consistent SSH keys, I'm afraid there is little choice but
to discard the use of known_hosts.

On 28 August 2015 at 15:10, Nico Kadel-Garcia <nkadel at gmail.com>
wrote:
>
> In environments where critical server hostnames and IP addresses are
> not tied to consistent SSH keys, I'm afraid there is little choice but
> to discard the use of known_hosts.
>
Shouldn't in such complex environments configuration management
pre-generate known_hosts from collected facts from hosts?

I know it is a hassle, but having a fuse that ensures that you are indeed
connecting to what you think you are connecting to is something worth
having, or not?

b.

On Fri, Aug 28, 2015 at 10:37 AM, Bostjan Skufca <bostjan at a2o.si>
wrote:
>
> On 28 August 2015 at 15:10, Nico Kadel-Garcia <nkadel at gmail.com>
wrote:
>>
>> In environments where critical server hostnames and IP addresses are
>> not tied to consistent SSH keys, I'm afraid there is little choice
but
>> to discard the use of known_hosts.
>
>
> Shouldn't in such complex environments configuration management
pre-generate
> known_hosts from collected facts from hosts?
At first glance, that sounds like a great idea. From harsh experience,
the man-hours and system resources and system integration blown on
building and maintaining and publishing such a system, and keeping it
synced despite the phase lag between the DHCP or system re-allocaiton
systems is dangerous, and it's much worse in an AD or Samba version of
dynamic DNS used to register wandering laptops. And now, as IPv4
addressea are finally being used up and companies are scrambling to
re-arrange and re-allocate IP space, the addresses are even more
likely to be re-used for another host with another key.

I simply don't see many graceful ways to track *all possible* hostkey
address spaces, and to find *everybody's* accidentally locally
published known_hosts to scrub them of entries that are in the
system's /etc/ssh/known_hosts or similar file.

My favorite recent example of where it bites me is small test or
staging environments, where the host keys for new test hosts are
generated dynamically and the IP addresses are re-used. It's so much
faster to simply turn off hostkeys altogether and make it stop
whinging at me, it seems much more effective than building and
maintaining an authorized_)keys generation tool. The payoff is very
small for all the work.
> I know it is a hassle, but having a fuse that ensures that you are indeed
> connecting to what you think you are connecting to is something worth
> having, or not?
>
> b.
For environments where IP addresses are consistent for the same IP
address, it can be useful.  But it's cycles of setup and maintainence
better used elsewhere in the environments I've mentioned.