On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern <Jochen.Bern at binect.de> 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 ofMany 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.
On 06/01/2022 06:08, Nico Kadel-Garcia wrote:> On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern<Jochen.Bern at binect.de> 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. >I agree. I find HashKnownHosts annoying, and I always turn it off when I remember to do so.? Typically this happens when I need to trim some entries from known_hosts, and then I find it has been hashing it up to the current point in time. Of course, I shouldn't have to turn it off, because the default is 'no',? I guess many distros set 'HashKnownHosts yes' in /etc/ssh/ssh_config because they want to be seen to choose the "secure" option by default. However the threat model seems pretty pointless to me.? If an attacker has access to my account to the level that they can read my known_hosts file, then I have far worse problems than them seeing a list of hostnames, which they can obtain in many other ways. Should I care about other system users reading this info, there's always chmod 700 (on the .ssh directory, or my whole home directory).? If known_hosts itself were created mode 600 by default, I wouldn't object.
mark dominik bürkle
2022-Jan-06 12:54 UTC
hosts with gateway for hostkey checking? (was: Re: Host names hashing)
hello all, besides from accessing "same" ips in a vlan env i see two more possibilities that might be in widespread use: - vlan env - administering home office (or friends') pcs - customers accessed via (multiple) vpn most of these will have different gateway ips. (or just different interfaces?) so, for these users, finding the gw (eg via "ip route get <target>" as shell cmd) and combining this with the hostname/ip for the known_hosts lookup might be helpful. with an option like KnownHostsUseGw <host_list> the known_host_entry might then be extended like <known_host_entry> ":via_" <gw> or <known_host_entry> ":via_" <device> [this may lead to problems with older implementations by ":<port>" confusion, to be considered before implementation.] accepting already existing matching entries and/or "unique" hosts: additionally to searching "...:via_<gw>", if not found, check "<host_without_gw>" or add option KnownHostsUseGwFallback (bool / pattern / behaviour_algo / external_cmd)? feasible, justified, any opinions? [side note: in combination with ansible (or other mgmt software) the installation process should be changed to record the correct (new, replaced) host keys, those then retrieved and verification NOT be turned off. might involve using ssh-keygen; complex setups should have the appropriate "gw" information.] thank you, mdbuerkle Am 6. Januar 2022 07:08:09 MEZ schrieb Nico Kadel-Garcia <nkadel at gmail.com>:>On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern <Jochen.Bern at binect.de> 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 at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.