[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com
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.


Reply to: