Human readable .ssh/known_hosts?

Nico Kadel-Garcia nkadel at gmail.com
Tue Sep 29 23:12:48 AEST 2020


On Tue, Sep 29, 2020 at 6:29 AM Martin Drescher <drescher at snafu.de> wrote:
>
> Hi list members,
>
> just tried to get some old records out of my known_hosts, which is 'HashKnownHosts yes'. Is there a way to unhash host names and/or IPs?
> Google tells about, how to add hosts, but not the opposite, may be I miss some thing.
> Is this does not work at all, is there a best practice for cleaning old hosts and keys out?

I gave up on $HOME/.ssh/known_hosts a *long* time ago, because if
servers are DHCP distributed without static IP addresses they can wind
up overlapping IP addresses with mismatched hostkeys in an internal
addr4ess. Since most of the traffic for SSH is for internal hosts,
known_hosts is usually far more likely to break valid services than to
provide useful filtering, and has been worse than useless since ssh-1
was written in 1995.

There are setups SSH targets where it is useful for, primarily
externally and consistentlyconfigured hosts with stable DNS and
hostkeys, such as github or gitlab. But for internal services, it's
generally far more trouble than it's worth. To disable it universally,
put th4ese in $HOME/.ssh/config:

    Host *
        StrictHostKeyChecking no
        UserKnownHostsFile=/dev/null
        LogLevel=ERROR

These can be reset as desired for hosts that might have reliably
consistent DNS and hostkeys, but hostkeys have long proven to cost far
more time and effort when altered for legitimate reasons than helpful
in identifying malicious man-in-the-middle attacks. They've been far
more useful as critifcal components of providing an encrypted session
than for identifying the host.

This has been the case since SSH-1 was written in 1995.


More information about the openssh-unix-dev mailing list