[Bug 3780] connecting using KexAlgorithms list fails without spaces

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Fri Jan 24 20:12:56 AEDT 2025


https://bugzilla.mindrot.org/show_bug.cgi?id=3780

--- Comment #7 from Darren Tucker <dtucker at 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.


More information about the openssh-bugs mailing list