How to fix debug1: expecting SSH2_MSG_KEX_ECDH_REPLY in SSH

SSHINTERMEDIATEHIGHUpdated Sep 12, 2026· 591 views

SSH connections hang indefinitely during the key exchange phase, displaying the debug message 'expecting SSH2_MSG_KEX_ECDH_REPLY'. This is typically caused by network path MTU issues, firewall rules blocking fragmentation packets, or ICMP configuration problems that prevent proper key exchange negotiation.

Quick fix

Fixes debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

ssh -vv user@host
  1. Verify the issue with verbose SSH debugging
  2. Test with different key exchange algorithms
  3. Lower the MTU on your connection
  4. Check and adjust firewall IPv6 rules
ssh — error
ssh -vv user@host
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

What this error means

This message indicates SSH is waiting for the server's ECDH (Elliptic Curve Diffie-Hellman) reply during the cryptographic key exchange phase. When the connection hangs at this point, the SSH client never receives the expected response from the server. This is almost always a network-level issue rather than an authentication or SSH configuration problem. The key exchange is the first critical step in establishing an SSH connection, and any interruption at this stage prevents the connection from proceeding to authentication.

Typical symptoms

  • SSH connections hang indefinitely or until timeout
  • Connection works fine with `ssh -vv` verbose debugging but hangs otherwise
  • Some hosts work fine while others consistently hang at key exchange
  • Works over Ethernet but hangs over WiFi or VPN connections
  • Works from certain systems/networks but fails from others
  • Connections hang specifically during the ECDH key exchange phase
  • Similar issues with SCP, SFTP, or other SSH-based tools

Common causes

  1. MTU (Maximum Transmission Unit) mismatch causing packet fragmentation that is dropped or not properly reassembled
  2. Firewall rules or network appliances blocking ICMP Fragmentation Needed messages required for Path MTU Discovery
  3. VPN or tunnel configurations with MTU settings incompatible with SSH key exchange packets
  4. IPv6 firewall rules (such as 'Allow-ICMPv6-Input' or 'Allow-ICMPv6-Forward') blocking necessary protocol messages
  5. Network intermediate devices (routers, switches, firewalls) silently dropping large packets without notification
  6. DTLS (Datagram TLS) interference when using VPN connections
  7. WSL2-specific networking issues where packets are dropped between Windows and Linux

How to fix "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"

1Verify the issue with verbose SSH debugging

Use SSH verbose mode to confirm the connection hangs at ECDH key exchange:

bash
ssh -vv user@host

Look for the line debug1: expecting SSH2_MSG_KEX_ECDH_REPLY where it hangs. This confirms it's the key exchange phase blocking.

2Test with different key exchange algorithms

Try forcing a different key exchange algorithm to bypass potential algorithm-specific issues:

bash
ssh -o KexAlgorithms=curve25519-sha256 user@host

If this works, add it to your ~/.ssh/config for that specific host:

bash
Host problematic-host
  HostName example.com
  User username
  KexAlgorithms curve25519-sha256
3Lower the MTU on your connection

MTU issues are the most common cause. Try lowering the MTU to force smaller SSH packets:

bash
# On Linux - temporarily change MTU to 1200
ip link set dev eth0 mtu 1200

# Or permanently (add to /etc/network/interfaces or netplan)
auto eth0
iface eth0 inet dhcp
  mtu 1200

# On macOS
networksetup -setmtu Ethernet 1200

Then try SSH again. If this fixes it, gradually increase MTU (1300, 1400, 1500) to find the working threshold.

4Check and adjust firewall IPv6 rules

If using IPv6 or on OpenWrt/Linux, verify that ICMP rules aren't blocking necessary messages:

bash
# View current firewall rules
sudo iptables -L -n
sudo ip6tables -L -n

# Check for rules blocking ICMP Fragmentation Needed
sudo iptables -L -n | grep -i icmp
sudo ip6tables -L -n | grep -i icmp

If you see rules like 'Allow-ICMPv6-Input' or similar, consider disabling or adjusting them. In OpenWrt Web UI, navigate to Network > Firewall > Traffic Rules and disable or delete problematic ICMP rules.

5Disable DTLS if using VPN

If SSH is going through a VPN connection, DTLS can interfere with key exchange:

bash
# For OpenVPN, edit your config and add:
disable-dco

Or in OpenVPN GUI, check the DTLS settings and disable DTLS encryption if enabled. Then reconnect and retry SSH.

6Verify packets with tcpdump (advanced diagnosis)

Capture network packets to see what's happening at the network level:

bash
# Capture SSH traffic to file
sudo tcpdump -i eth0 -n 'tcp port 22' -w ssh_capture.pcap

# In another terminal, try SSH
ssh user@host

# Stop tcpdump (Ctrl+C), then analyze
tcpdump -r ssh_capture.pcap | head -50

Look for retransmitted packets or gaps where responses should appear. If you see many retransmissions, it's a packet loss/MTU issue. If responses stop, it's a firewall/drop issue.

7Contact your network administrator

If none of the above work, provide your network administrator with:

1. The verbose SSH output from step 1
2. MTU settings from step 3 that worked (if any)
3. Your firewall rules from step 4
4. tcpdump output from step 6 (if available)

Request that they:
- Verify MTU settings on both client and server network interfaces
- Check if ICMP is being properly allowed for Path MTU Discovery
- Review firewall rules for anything blocking large packets
- Confirm no proxy or transparent firewall is interfering with SSH

Advanced notes

Path MTU Discovery: SSH key exchange packets can be large (especially with ECDH). If a router along the path expects smaller packets, it sends an ICMP 'Fragmentation Needed' message. If this message is blocked by a firewall, the client has no way to know it should send smaller packets, leading to this hang.

WSL2 Specifics: Windows Subsystem for Linux 2 has reported this issue where SSH works from PowerShell but hangs from WSL. This is due to WSL2's networking layer and may require updating WSL2 or using the workarounds above.

Temporary vs. Permanent Fix: Lowering MTU is a workaround, not a proper fix. The real issue is the network path not supporting Path MTU Discovery. Work with your network administrator to fix the underlying cause rather than permanently reducing MTU.

Frequently asked questions

What does "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY" mean?
This message indicates SSH is waiting for the server's ECDH (Elliptic Curve Diffie-Hellman) reply during the cryptographic key exchange phase. When the connection hangs at this point, the SSH client never receives the expected response from the server. This is almost always a network-level issue rather than an authentication or SSH configuration problem.
How do I fix "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"?
SSH connections hang indefinitely during the key exchange phase, displaying the debug message 'expecting SSH2_MSG_KEX_ECDH_REPLY'. This is typically caused by network path MTU issues, firewall rules blocking fragmentation packets, or ICMP configuration problems that prevent proper key exchange negotiation.
What causes "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"?
MTU (Maximum Transmission Unit) mismatch causing packet fragmentation that is dropped or not properly reassembled Firewall rules or network appliances blocking ICMP Fragmentation Needed messages required for Path MTU Discovery VPN or tunnel configurations with MTU settings incompatible with SSH key exchange packets
Is the "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading