How to fix debug1: expecting SSH2_MSG_KEX_ECDH_REPLY in SSH

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

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.

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

ssh -o KexAlgorithms=curve25519-sha256 user@host

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

Host problematic-host
  HostName example.com
  User username
  KexAlgorithms curve25519-sha256

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

# 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.

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

# 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.

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

# 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.

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

# 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.

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