openssh bugs - Jan 2025 - [Bug 3781] New: IPv6 inconsistency causes TOFU

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

            Bug ID: 3781
           Summary: IPv6 inconsistency causes TOFU
           Product: Portable OpenSSH
           Version: 9.7p1
          Hardware: All
                OS: Other
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: sshbugs.to.davies at spamgourmet.com

I have anonymised potentially identifiable data in my commands and
outputs. I have been allocated a /64 IPv6 range, the fourth group of
which is 0. If I replace the IPv6 host pattern in known_hosts with
xxxx:yyyy:zzzz:*, the certificate works, but would also work for
networks outside my allocated range. If I change it to
xxxx:yyyy:zzzz::* it also works for this particular address, but fails
for some addresses that are generated dynamically. The only solution I
can see is to use two patterns for the same range. This breaks the
principles of both least astonishment and DRY. Since, as demonstrated
by the second test, ssh converts IPv6 addresses from the command line,
would it be possible to carry out the same conversion on addresses from
known_hosts? Perhaps CIDR would do the job. If not, please could this
behaviour and the need for two ranges (or a better workaround) be
documented somewhere?

C:\Users\Administrator>c:\cwrsync_6.3.0_x64_free\bin\ssh
user at xxxx:yyyy:zzzz::f3
The authenticity of host 'xxxx:yyyy:zzzz::f3 (xxxx:yyyy:zzzz::f3)'
can't be established.
ED25519 key fingerprint is
SHA256:qwerqwerqwerqwerqwerqwerqwerqwerqwerqwerqwe.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.

C:\Users\Administrator>c:\cwrsync_6.3.0_x64_free\bin\ssh
user at xxxx:yyyy:zzzz:0::f3
The authenticity of host 'xxxx:yyyy:zzzz::f3 (xxxx:yyyy:zzzz::f3)'
can't be established.
ED25519 key fingerprint is
SHA256:qwerqwerqwerqwerqwerqwerqwerqwerqwerqwerqwe.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.

C:\Users\Administrator>cat \cwrsync_6.3.0_x64_free\known_hosts
@cert-authority
*.lan.xxxxxxxxxxxxxx,192.168.51.*,192.168.1.*,192.168.13.*,xxxx:yyyy:zzzz:0:*
ssh-ed25519
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf
host_ca.pub

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
It's hard to tell what is going on without debug traces from your ssh
client.

What ssh client are you using? If you're using the Windows built-in ssh
client, then you should direct your report to Microsoft as they heavily
modify the code that we ship.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #2 from sshbugs.to.davies at spamgourmet.com ---
Created attachment 3857
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3857&action=edit
ssh -vvv output

The attachment shows the debug trace, with some data anonymised again
and a few "Ignoring" lines omitted.

I'm using the ssh client that came with cwRsync, which may mean that
the bug would be better handled by them. I have tried using the Windows
and Debian clients, but they behave correctly on other machines.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #3 from Damien Miller <djm at mindrot.org>
---
> If I change it to xxxx:yyyy:zzzz::* it also works for this
> particular address, but fails for some addresses that are
> generated dynamically
Is the debug trace an example of this? What was in known_hosts when you
generated the trace? What sort of addresses does this fail for?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Also, what do you mean by "addresses that are generated dynamically" ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #5 from sshbugs.to.davies at spamgourmet.com
---
> Is the debug trace an example of this?
Yes.
> What was in known_hosts when you generated the trace?
As stated in my original report, but repeated for convenience with
anonymisation retained:
C:\Users\Administrator>cat \cwrsync_6.3.0_x64_free\known_hosts
@cert-authority
*.lan.xxxxxxxxxxxxxx,192.168.51.*,192.168.1.*,192.168.13.*,xxxx:yyyy:zzzz:0:*
ssh-ed25519
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf
host_ca.pub
> What sort of addresses does this fail for?
IPv6 addresses of the form xxxx:yyyy:zzzz::anything.
> Also, what do you mean by "addresses that are generated
dynamically" ?
Addresses generated by DHCP6, as ULAs or by similar processes;
addresses that are not static and therefore may contain any unique
value in the last 64 bits.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
xxxx:yyyy:zzzz::f3

(In reply to sshbugs.to.davies from comment #5)
> > Is the debug trace an example of this?
> Yes.
> 
> > What was in known_hosts when you generated the trace?
> As stated in my original report, but repeated for convenience with
> anonymisation retained:
> C:\Users\Administrator>cat \cwrsync_6.3.0_x64_free\known_hosts
> @cert-authority
> *.lan.xxxxxxxxxxxxxx,192.168.51.*,192.168.1.*,192.168.13.*,xxxx:yyyy:
> zzzz:0:* ssh-ed25519
> asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf
> host_ca.pub
That pattern is guaranteed not to work because the address wildcard
xxxx:yyyy:zzzz:0:* won't match the normalised address
xxxx:yyyy:zzzz::f3
> > What sort of addresses does this fail for?
> IPv6 addresses of the form xxxx:yyyy:zzzz::anything.
> 
> > Also, what do you mean by "addresses that are generated
dynamically" ?
> Addresses generated by DHCP6, as ULAs or by similar processes;
> addresses that are not static and therefore may contain any unique
> value in the last 64 bits.
Do you mean the last 64 bits or the last 48? If you have a /64, why are
you allocating dynamic addresses with non-zero bytes 7-8?

Basically I'm not understanding how/why xxxx:yyyy:zzzz::* is failing
for you, as that is the form that you should be using.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #7 from sshbugs.to.davies at spamgourmet.com ---
I have a /64. I am not allocating anything other than zeros in bytes
7-8. And yet, as shown in my original post, ::f3 fails.

As I said in my second post, "I'm using the ssh client that came with
cwRsync, which may mean that the bug would be better handled by them. I
have tried using the Windows and Debian clients, but they behave
correctly on other machines". If you cannot reproduce the issue, that
suggests even more strongly that someone responsible for the version
issued with cwRsync has done something unpatriotic. Can this be
confirmed or denied by anyone at your end?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3781

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
No, we have no ability to reproduce problems in cwRsync

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.