On Wed, 30 Sep 2020 at 11:09, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
> On Tue, Sep 29, 2020 at 8:22 PM Darren Tucker <dtucker@xxxxxxxxxxx> wrote:
> > [...] CheckHostIP [...]
> As I understand this option, it does not help at all with the nearly
> inevitable re-use of the same IP address for a different host with a
> different hostkey in, for example, a modest DHCP based environment.
I don't follow your reasoning here. If you set CheckHostIP=no then
ssh does not store or check IP addresses at all, so how can a host's
reuse of IP addresses cause an issue, so long as the host's hostkey
and the client's idea of its name (or hostkeyalias) remain the same?
Or are your hostnames not stable either?
$ ssh -o checkhostip=no -o userknownhostsfile=/tmp/hosts somehost
$ cat /tmp/hosts
somehost ecdsa-sha2-nistp256 AAAA [etc]
$ ssh -o checkhostip=yes -o userknownhostsfile=/tmp/hosts somehost
Warning: Permanently added the ECDSA host key for IP address
'192.168.32.1' to the list of known hosts.
$ cat /tmp/hosts
somehost ecdsa-sha2-nistp256 AAAA [etc]
192.168.32.1 ecdsa-sha2-nistp256 AAAA [etc]
If I then replace the IP address one with the fingerprint from another
host, i complains with CheckHostIP=yes as expected:
$ ssh -o checkhostip=yes -o userknownhostsfile=/tmp/hosts somehost echo it works
Warning: the ECDSA host key for 'somehost differs from the key for the
IP address '192.168.32.1'
Offending key for IP in /tmp/hosts:2
Matching host key in /tmp/hosts:1
but works fine with CheckHostIP=no:
$ ssh -o checkhostip=no -o userknownhostsfile=/tmp/hosts gate echo it works
it works
The other thing you could do (and this is new in OpenSSH 8.4) is you
can use %-TOKEN expansion on UserKnownHostsFile to store hostkeys in
per-host files, eg:
UserKnownHostsFile ~/.ssh/known_hosts.d/%k
which will cause the host keys, including per-IP keys if enabled, to
be stored in separate files per host.
--
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
