On Fri, Aug 28, 2015 at 10:37 AM, Bostjan Skufca <bostjan@xxxxxx> wrote: > > On 28 August 2015 at 15:10, Nico Kadel-Garcia <nkadel@xxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
