On Mon, 26 Oct 2020, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 23 2020, Damien Miller <[email protected]> wrote:
> > On Fri, 23 Oct 2020, Jeremie Courreges-Anglas wrote:
> >
> >>
> >> I upgraded my ports builder from snaps yesterday and I hit this when
> >> running cvs up:
[big snip]
I think I have replicated your problem. Can you roll your known_hosts
back to just the ecdsa-sha2-nistp256 keys, apply this patch and attempt
a few connections? You should see no more conflicts between IPv4/IPv6
addresses.
diff --git a/clientloop.c b/clientloop.c
index cda0845..9f25950 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -2277,7 +2277,7 @@ client_input_hostkeys(struct ssh *ssh)
ctx->ip_str ? ctx->ip_str : "(none)");
if ((r = hostkeys_foreach(options.user_hostfiles[i],
hostkeys_find, ctx, ctx->host_str, ctx->ip_str,
- HKF_WANT_PARSE_KEY|HKF_WANT_MATCH)) != 0) {
+ HKF_WANT_PARSE_KEY)) != 0) {
if (r == SSH_ERR_SYSTEM_ERROR && errno == ENOENT) {
debug_f("hostkeys file %s does not exist",
options.user_hostfiles[i]);
Explanation: in clientloop.c r1.353 I added some additional checks to
stop UpdateHostKeys that were intended to prevent exactly this situation.
Unfortunately I forgot to flip the flag to allow the new code to actually
execute.
Basically, clientloop.c:hostkeys_find() will try look for host keys on
known_hosts lines that *do not* match the current hostname/IP and disable
UpdateHostkeys if they exist. However, the above HKF_WANT_MATCH flag was
causing hostkeys_find() to only ever be called with matching lines.
I missed this when I did my testing, because I tried a subtly different
case: known_hosts lines with non-matching IP addresses but matching
hostnames. These make it through the HKF_WANT_MATCH filter.
-d
