Human readable .ssh/known_hosts?

[Demi M. Obenour]

On 2020-09-29 09:12, Nico Kadel-Garcia wrote:
> 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.

There are several alternative solutions, all of which are better than
disabling host key verification:

- You can place SSH host keys in DNS, and sign then with DNSSEC.
  You can then run a local recursive resolver, such as Unwind or
  Unbound (both in the OpenBSD base system), which validates DNSSEC.
  ssh(1) can then check the server’s host keys against the SSHFP
  DNS records.
- You can use SSH certificates.  Each server presents a certificate to
  attest to its identity.  The certificate contains both the public
  host key and a signature made by a trusted certificate authority.
  If the certificate authority only signs legitimate certificates,
  the identity of a server cannot be forged.
- You can use GSSAPI key exchange.  OpenSSH doesn’t support this
  natively, but there is a widely available patch that adds support
  for it.  With GSSAPI key exchange, the client and server authenticate
  each other using their Kerberos credentials.  This works best if
  the machines are joined to a domain in a directory service, such
  as FreeIPA or Active Directory.

Sincerely,

Demi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200929/ea56dac1/attachment-0001.asc>