openssh unix dev - Oct 2024 - SSH host key rotation – known_hosts file not updated

On Mon, Oct 14, 2024 at 5:33?AM Jan Eden via openssh-unix-dev
<openssh-unix-dev at mindrot.org> wrote:
redacted hostname and port ? sorry, should have mentioned
that.
>
> > Anyway, in answer to your question. The "host key found matching
a different
> > name/address" is triggered when a key received from the server in
an update
> > already exists under a different name. If you turn the debugging level
up,
> > then you'll see the name(s) that it matches too:
> >
> >   2100          if (sshkey_equal(l->key, ctx->keys[i])) {
> >   2101                  ctx->other_name_seen = 1;
> >   2102                  debug3_f("found %s key under different
"
> >   2103                      "name/addr at %s:%ld",
> >   2104                      sshkey_ssh_name(ctx->keys[i]),
> >   2105                      l->path, l->linenum);
> >   2106                  return 0;
> >   2107          }
> >   2108  }
>
> Thank you! Increasing the verbosity revealed a known_hosts entry linked
> to serverA's IP address (I had forgotten that I had connected to it by
> IP address at some point). Deleting this entry solved the problem; the
> new host key was stored in known_hosts when I connected to serverA
> again.
>
> - Jan
And... *THIS* is why so many people disable known_hosts entirely. The
chance of an IP address being reused for a distinct hostname is pretty
high in a DHCP environment without reservations, coupled with dynamic
DNS. It's also very common when servers get rebuilt from images and
fresh hostkeys generated automatically on the same hardware, even with
the same IP address. The popular solution is to simply disable
known_hosts in your ~/.ssh/config as needed:

    # Disable known_hosts to avoid IP re-use conflicts
    Host *
         UserKnownHostsFile /dev/null
          StrictHostKeyChecking no
          LogLevel ERROR

Nico Kadel-Garcia wrote:
> And... *THIS* is why so many people disable known_hosts entirely. The
> chance of an IP address being reused for a distinct hostname is pretty
> high in a DHCP environment without reservations, coupled with dynamic
> DNS. It's also very common when servers get rebuilt from images and
> fresh hostkeys generated automatically on the same hardware, even with
> the same IP address. The popular solution is to simply disable
> known_hosts in your ~/.ssh/config as needed:
I mitigate this in two different ways.  For one if servers are getting
rebuilt routinely such as for testing or for scaling-out or just
normal replacement then I always install the same role key for those
servers.  It's a replacement for a previous server?  Then it gets the
same role key as the prior server.

The second thing I do is I build a global ssh_known_hosts with the
known host keys of the dynamic server pool systems.  Since the key is
in the system level ssh_known_hosts then it doesn't get added to user
level known_hosts file.  And the system level file is updated as
needed.

That's not to say that I don't /dev/null host keys in some cases too.
Here if I connect to an IP address then I know it is just a one-off
not to be saved and I discard host keys in that case.

Bob

On 2024-10-17 19:26, Nico Kadel-Garcia wrote:
> > Thank you! Increasing the verbosity revealed a known_hosts entry
linked
> > to serverA's IP address (I had forgotten that I had connected to
it by
> > IP address at some point). Deleting this entry solved the problem; the
> > new host key was stored in known_hosts when I connected to serverA
> > again.
> >
> > - Jan
> 
> And... *THIS* is why so many people disable known_hosts entirely. The
> chance of an IP address being reused for a distinct hostname is pretty
> high in a DHCP environment without reservations, coupled with dynamic
> DNS. It's also very common when servers get rebuilt from images and
> fresh hostkeys generated automatically on the same hardware, even with
> the same IP address. The popular solution is to simply disable
> known_hosts in your ~/.ssh/config as needed:
> 
>     # Disable known_hosts to avoid IP re-use conflicts
>     Host *
>          UserKnownHostsFile /dev/null
>           StrictHostKeyChecking no
>           LogLevel ERROR
Thanks for the hint. How would I verify a server's identity without
known_hosts / StrictHostKeyChecking?

- Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20241018/972a12a0/attachment-0001.asc>