Executive summary: Browsers need short-lived addresses which can't be
tracked whereas ssh needs long-lived addresses which ensure that
connections aren't cut after a couple of hours.

Long explanation:

By default, IPv6 creates client addresses which contain the client PC's
MAC address, which exposes the user to tracking by malicious web
servers or ad networks.

That's why RFC 3041 introduced privacy extensions which allow to set up
"temporary" addresses which don't contain the MAC, but which are
recycled quickly. The temporary address is defined in _addition_ to the
public address. The temporary address is to be used for outgoing
connection by exposed programs, such as web browsers. The public
address is to be used for incoming connections (where PC is a server),
and by long-lived clients such as openssh which connect to trusted
servers

https://home.regit.org/2011/04/ipv6-privacy/
sysctl -w net.ipv6.conf.eth0.use_tempaddr=2

The issue: openssh too uses the temporary address, leading to
connection interruptions whenever the address cycles, or at least such
behavior should be configurable.

Openssh should use
setsockopt(socket, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &value,
sizeof(value))
to explicitly opt for the public address.

See also this bug on RedHat (which suggests to make the behavior
configurable):
https://bugzilla.redhat.com/show_bug.cgi?id=512032


Thanks,

Alain

I've implemented this feature (making it configurable with an option)
and submitted it to upstream ML [1], but the only feedback I got from
the developers was negative, apparently because this functionality is
Linux-specific (which it only is because no other OS implements the
relevant RFC).

Later I've submitted a version of the patch without the option [2],
hoping that would make it more acceptable to upstream, but received no
feedback whatsoever.

Would it be conceivable for Debian to include either of these patches in
its packages? I believe they are quite simple and non-invasive
(especially the second version - I can understand that adding new
options over what upstream has might be undesirable) and very unlikely
to cause any issues.

[1] https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-April/039301.html
[2] https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-July/039449.html

Cheers,