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? Thanks, Martin! -- Martin GnuPG Key Fingerprint, KeyID '4FBE451A': '2237 1E95 8E50 E825 9FE8 AEE1 6FF4 1E34 4FBE 451A'
On Tue, 29 Sep 2020, Martin Drescher 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?The hashing is intentionally one-way - you can't go backwards from a hash to a hostname without an inordinate amount of work. You can however find and delete hosts by name using ssh-keygen. To find entries matching a hostname, use "ssh-keygen -F hostname", e.g. $ ssh-keygen -lF haru.mindrot.org # Host haru.mindrot.org found: line 146 haru.mindrot.org ECDSA SHA256:xjGrsgS6JzMojD3go1qULmh02LG8YpRirOwmoHnT/3M # Host haru.mindrot.org found: line 165 haru.mindrot.org RSA SHA256:9nN+SOkKCQq6BLzybAUNlczAU0n+HbOIDxIrBIbPPmU # Host haru.mindrot.org found: line 166 haru.mindrot.org ED25519 SHA256:43S30LGUkc2f9dDcLZG6O5KPKtPn7Xw2WkR2vCO/nnU (the -l flag tells it to print fingerprints instead of full keys) You can also delete entries using "ssh-keygen -R hostname". -d
Martin Drescher kirjoitti tiistai 29. syyskuuta 2020:> 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?Unfortunately not. Hashing is one-way process by definition and you should not be able to get the input from a hash. - juice - -- Sent from my SFOS/XperiaX
On 29.09.20 12:44, Damien Miller wrote:> On Tue, 29 Sep 2020, Martin Drescher wrote: > >> Hi list members,[...]> You can however find and delete hosts by name using ssh-keygen.> > To find entries matching a hostname, use "ssh-keygen -F hostname", e.g.The point is, file has over 600 hashes stored.> $ ssh-keygen -lF haru.mindrot.org > # Host haru.mindrot.org found: line 146 > haru.mindrot.org ECDSA SHA256:xjGrsgS6JzMojD3go1qULmh02LG8YpRirOwmoHnT/3M > # Host haru.mindrot.org found: line 165 > haru.mindrot.org RSA SHA256:9nN+SOkKCQq6BLzybAUNlczAU0n+HbOIDxIrBIbPPmU > # Host haru.mindrot.org found: line 166 > haru.mindrot.org ED25519 SHA256:43S30LGUkc2f9dDcLZG6O5KPKtPn7Xw2WkR2vCO/nnU > > (the -l flag tells it to print fingerprints instead of full keys) > > You can also delete entries using "ssh-keygen -R hostname". > > -dAt this point, my best practice would possibly be, to start with an empty known host and build a new one from all hosts in my .ssh/config. How would a 'lasst_seen' column in known_hosts be a nice feature? I'm not sure. -- Martin
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.
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>
On Tue, 29 Sep 2020, Nico Kadel-Garcia wrote:> 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.FWIW I think this is bad advice. Services are only "internal" to the extent that you can trust your network. Search "SSL added and removed here" for a practical demonstration of this assumption yielding undesirable results. Disabling hostkey checking is a big hammer, but occasionally useful for lab environments. Generally I recommend that people who are having trouble with hostkey management consider using host certificates. -d
On Tue, 29 Sep 2020 at 23:16, Nico Kadel-Garcia <nkadel at gmail.com> wrote: [...]> 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 hostkeysYou can set CheckHostIP=no in your config. As long as the names don't change it'll do what you want, and it's far safer than what you suggest. [...]> This has been the case since SSH-1 was written in 1995.CheckHostIP was added to OpenSSH in 1999 before the first release and has been in every release since: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.7&r2=1.8&f=h -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On Tue, Sep 29, 2020 at 6:46 AM Damien Miller <djm at mindrot.org> wrote:> > On Tue, 29 Sep 2020, Martin Drescher 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? > > The hashing is intentionally one-way - you can't go backwards from a > hash to a hostname without an inordinate amount of work. > > You can however find and delete hosts by name using ssh-keygen. > > To find entries matching a hostname, use "ssh-keygen -F hostname", e.g. > > $ ssh-keygen -lF haru.mindrot.org > # Host haru.mindrot.org found: line 146 > haru.mindrot.org ECDSA SHA256:xjGrsgS6JzMojD3go1qULmh02LG8YpRirOwmoHnT/3M > # Host haru.mindrot.org found: line 165 > haru.mindrot.org RSA SHA256:9nN+SOkKCQq6BLzybAUNlczAU0n+HbOIDxIrBIbPPmU > # Host haru.mindrot.org found: line 166 > haru.mindrot.org ED25519 SHA256:43S30LGUkc2f9dDcLZG6O5KPKtPn7Xw2WkR2vCO/nnU >One a side note, I see *some* entries in .ssh/known_hosts showing the hostname or IP, while others do not. What causes this lack of consistency?> (the -l flag tells it to print fingerprints instead of full keys) > > You can also delete entries using "ssh-keygen -R hostname". > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Hi list, what confuses me a bit is this shell(?) magic: When I type 'ssh ' on my console an hit the TAB twice, I get a list of host I would probably ssh to. This list does not come from an element in my bash history. On my initial question, I guessed this would somehow come from the known_hosts file. Does it? Can someone tell how this magic works? Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20201001/d0be4c6a/attachment.asc>
Hi Martin, Martin Drescher wrote on Thu, Oct 01, 2020 at 02:06:22PM +0200:> Can someone tell how this magic works?No, and this question is off-topic on this list because it is not related to OpenSSH. It is a question about your shell, and about how the configuration of your shell works, and you don't even provide information about how you have configured your shell. Yours, Ingo
check the shell?s configuration and plugins w.r.t. tab completion (I know at least there is a ZSH plugin doing that for me in the Oh-My-Zsh templates)> On 01 Oct 2020, at 14:06 , Martin Drescher <drescher at snafu.de> wrote: > > Signed PGP part > Hi list, > > what confuses me a bit is this shell(?) magic: When I type 'ssh ' on my console an hit the TAB twice, I get a list of host I would probably ssh to. This list does not come from an element in my bash history. On my initial question, I guessed this would somehow come from the known_hosts file. Does it? > Can someone tell how this magic works? > > Thanks, Martin > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20201001/e3d56e1f/attachment.asc>
On 01/10/2020 13:06, Martin Drescher wrote:> what confuses me a bit is this shell(?) magic: When I type 'ssh ' on my console an hit the TAB twice, I get a list of host I would probably ssh to. This list does not come from an element in my bash history. On my initial question, I guessed this would somehow come from the known_hosts file. Does it? > Can someone tell how this magic works?Under Ubuntu 18.04, it appears to be giving me everything in /etc/hosts *and* everything in ~/.ssh/known_hosts For the magic see: /usr/share/bash-completion/completions/ssh /usr/share/bash-completion/bash_completion?? # function _known_hosts_real()