Bug#990882: openssh-server: With ipv6 ssh-client fail as well as scp getting expecting SSH2_MSG_KEX_ECDH_REPLY

Hallo TImo

Le 11/07/2021 à 22:04, Timo Weingärtner a écrit :
> Hallo Daniel,
>
> 10.07.21 14:14 Daniel:
>> ssh and scp connecting smoothly. With the above MACs trick, scp connect
>> but then hangs on copy like
>>
>> Authenticated to myserver ([2001:db8:dead:beef::1]:22).
>> debug1: channel 0: new [client-session]
>> debug1: Requesting [email protected]
>> debug1: Entering interactive session.
>> debug1: pledge: network
>> debug1: client_input_global_request: rtype [email protected]
>> want_reply 0
>> debug1: Remote: /root/.ssh/authorized_keys:2: key options:
>> agent-forwarding port-forwarding pty user-rc x11-forwarding
>> debug1: Remote: /root/.ssh/authorized_keys:2: key options:
>> agent-forwarding port-forwarding pty user-rc x11-forwarding
>> debug1: Sending environment.
>> debug1: Sending env LANG = fr_FR.UTF-8
>> debug1: Sending command: scp -v -t /etc/bind/VarCacheBind/
>> Sending file modes: C0644 3079 file.txt
>> Sink: C0644 3079 file.txt
>> file.txt 0% 0 0.0KB/s --:-- ETA
> So actually the connection setup (small packets) works and the connection
> starts hanging when packets get big.
>
>> * What exactly did you do (or not do) that was effective (or
>> ineffective)?
>>
>> Adding MACs=hmacs-sha2-256 to .ssh/config solved the problem for ssh
>> client (Debian 9/10 & Ubuntu 18/20) but not for scp (Debian 9/10 &
>> Ubuntu 18/20)
> A quick test with wireshark shows: ssh client with default/no config sends a
> "Client: Key Exchange Init" with over 1500 Bytes. With that config change you
> likely dropped that below your PMTU.
>
> What is the network between client and server like? Does PMTUD work? Maybe
> there are non-conforming IPv6-implementations and/or misconfigured firewalls
> on the way?

This server has few interfaces, each having his own ipv6 address. The 
one I have a problem with is a tun interface from openvpn, other ipv6 
addresses connected to ethx interfaces doesn't present this problem. I 
tried with mtu 1492 (1500 is default), 1450 and 1440, no changes

The setup of this server is the same since long time and it worked 
perfectly till the system update of end june/early july.

I stopped the fw (nftables), no changes. Servers are located in DC 
(Hetzner).

How can I check if PMTUd is working ?

Thanks for your support

>> If we do the copy in ipv4 -by adding -4 in front of command- it copy
>> smoothly.
> Well, in IPv4 routers usually do fragmentation (lowering throughput/
> efficiency) instead of relying on PMTUD.