#990882 openssh-server: With ipv6 ssh-client fail as well as scp getting expecting SSH2_MSG_KEX_ECDH_REPLY #990882
- Package:
- openssh-server
- Source:
- openssh
- Description:
- secure shell (SSH) server, for secure access from remote machines
- Submitter:
- Daniel
- Date:
- 2021-07-15 15:48:02 UTC
- Severity:
- normal
- Tags:
Dear Maintainer, * What led up to the situation? We could't ssh to the server in ipv6, ipv4 was OK. After some times we discover that the problem also exists with scp, only ipv6 too. * 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) * What was the outcome of this action? System update begining of july (servers are updated each week on saturday) * What outcome did you expect instead? 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 where VarCacheBind is a symlink If we do the copy in ipv4 -by adding -4 in front of command- it copy smoothly.
Hallo Daniel, 10.07.21 14:14 Daniel: So actually the connection setup (small packets) works and the connection starts hanging when packets get big. "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? Well, in IPv4 routers usually do fragmentation (lowering throughput/ efficiency) instead of relying on PMTUD. Grüße Timo
Hallo TImo Le 11/07/2021 à 22:04, Timo Weingärtner a écrit : 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
Hallo TImo Le 11/07/2021 à 22:04, Timo Weingärtner a écrit : 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