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@gmail.com>:
>On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern <Jochen.Bern@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@mindrot.org
>https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
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@gmail.com>:
>On Wed, Jan 5, 2022 at 10:38 AM Jochen Bern <Jochen.Bern@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@mindrot.org
>https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev