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? > 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. Grüße Timo
Attachment:
signature.asc
Description: This is a digitally signed message part.