On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern <Jochen.Bern@xxxxxxxxx> wrote:
> The hashing is meant to obscure info about what host it matches, so the
> relevant failure mode is if the hash algo would become *reversible*.
And normally, it's the opposite of helpful. The known_hosts is useful
for casual review and for tuning .ssh/config as desired for more
specific uses, and the hashing obscures the commonly used SSH targets.
> One question about the real-world use cases, however: How many people
> are there hashing known_hosts entries *autogenerated by client use out
> of the very same account*? If I were to find that someone got ahold of
Many simply turn off known_hosts, because it is a burden to approve
new hostkeys and very awkward if there is an IP address overlap in a
DHCP or externally configured target. The .ssh/config settings for
this are quite old, and well documented:
Host *
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
LogLevel ERROR
> A much more understandable use case would be if an organization
> distributes a centrally administered/collected known_hosts file to users
> but doesn't want marginally-trusted users to immediately see where to
> find the company LAN's crown jewels. However, in order to make a
> successful algo migration in *that* scenario, we'd have to address the
> possibility that users and the central repository could end up
> supporting *different* sets of algos for some length of time ...
The burden is why I disable it in setups like, say, ansible server
setups to control wide varieties of VM's in a multi-purpose VLAN.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
