On 2024-10-14 14:48, Damien Miller wrote:> On Sun, 13 Oct 2024, Jan Eden via openssh-unix-dev wrote: > > When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) > > afterwards, known_hosts on the client is not updated. The output of the > > ssh command contains this: > > > > debug1: Host '[serverA.domain.internal]:22' is known and matches the ED25519 host key. > > # ... > > debug1: client_input_hostkeys: searching /Users/snafu/.ssh/known_hosts for [serverA.domain.internal]:22 / (none) > > debug1: client_input_hostkeys: searching /Users/snafu/.ssh/known_hosts2 for [serverA.domain.internal]:22 / (none) > > debug1: client_input_hostkeys: hostkeys file /Users/snafu/.ssh/known_hosts2 does not exist > > debug1: client_input_hostkeys: host key found matching a different name/address, skipping UserKnownHostsFile update> One weird thing is this: > > > debug1: Host '[serverA.domain.internal]:22' is known and matches the ED25519 host key. > > ssh doesn't usually decorate the hostname with port numbers like this for > the default port 22. Did you redact the output?Yes, I 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 -------------- 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/20241014/3bde6c22/attachment.asc>
Nico Kadel-Garcia
2024-Oct-17 23:26 UTC
Re: Re: 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. > > - JanAnd... *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