SSH Hangs at SSH2_MSG_KEX_ECDH_REPLY: It Is Not Always MTU

The tunnel is up, the banner arrives, and the client prints a message about waiting for the key-exchange reply. Search results point straight at MTU, and sometimes that is right. Often it is not: the reply may never have been sent, because the client could not read a key file or the ends never agreed on an algorithm. The line describes what the client is waiting for, not why the wait started. Treat it as a symptom and separate the three causes before changing any size.

Read the trace to see whether a reply was expected at all

Verbose output shows the last successful step before the silence. If the server's protocol banner arrived, TCP is working and the remote end is alive; the open question is what happened to one specific packet. A minute of silence after the banner looks like a path problem. A message about no matching key exchange method is a policy problem. A long wait that ends with the server closing the session means the server gave up, and its log explains why.

For the last case, read the server's authentication log before touching the client. The client cannot see a decision the server never sent.

Why a small reply can still be too large

Key-exchange replies are normally tiny, so blaming size sounds wrong. With host certificates the reply is not tiny, because it carries the server's certificate chain. That makes it the first packet in the session that can exceed the tunnel's usable payload. When path MTU discovery feedback is dropped somewhere along the route, the sender keeps retransmitting a packet that cannot fit, and the client waits forever at the same line.

Establish the size instead of assuming it. Read the tunnel MTU with ip link show tun0, then send probes that must not fragment: ping -4 -M do -s 1352 host, repeated with smaller payloads. A change from failure to success at a specific size is evidence; uniform failure suggests ICMP is filtered and tells you nothing.

A temporary reduction confirms the theory quickly, and a durable version belongs in the profile or as an MSS clamp on the router that forwards the tunnel:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

The two causes that imitate a size problem

A key file the client cannot read produces the same wait, with no warning even in verbose output. One known_hosts pattern makes this easy to hit: an @cert-authority entry pointing at a CA public key that only one account can read. The account that owns the file connects, and every other account hangs. If the failure follows the user rather than the host, check file modes before packet sizes.

An upgrade can also remove the algorithm both ends used to share. Pin a single method the server still offers as a diagnostic: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. A connection that succeeds immediately proves the path is fine and the fix belongs in the negotiation policy on both sides.

Three facts worth writing down

Record the tunnel MTU before and after any change, whether a large file copy fails at a repeatable size, and whether a certificate-free host on the same tunnel stalls identically. Those three observations separate size from permissions from negotiation faster than a stack of commands.

They also prevent the next person from lowering the MTU for a fault that was never about size.

If the picture is still unclear, test from a second client on the same tunnel. A client that connects moves the fault from the path to the first machine's configuration.