https://bugzilla.mindrot.org/show_bug.cgi?id=3780
--- Comment #7 from Darren Tucker <dtuc...@dtucker.net> --- > - it looks like supplying more than one kex algorithm always stops, waiting > for the reply of the remote end (see ssh_failed_log). > - the connection is via a wireguard tunnel That combination sounds like a Path MTU problem. One end (the client in this case) sends a packet larger than an MTU somewhere on the network path, the packet gets fragmented, (eg a firewall) drops the 2nd and subsequent fragments (because they don't have port information), and the first fragment times out waiting for reassembly on the other end. TCP retransmits the data, which is fragmented exactly the same way. In the case of SSH, the packet sizes are influenced by the algorithm lists, so adding the 2nd hostkey algo might be pushing the packet over the fragmentation limit. If this is what's happening, you will see the bytes stuck in the "SendQ" column of "nestat" for the TCP connection on one of the ends. The number will be non-zero and never decreasing, indicating that TCP never acks the data. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
