On 2020-09-29 09:12, Nico Kadel-Garcia wrote: > On Tue, Sep 29, 2020 at 6:29 AM Martin Drescher <drescher@xxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
