1

I'm trying to connect over SSH to a server, but this happens:

14:14:49 9 ~$ ssh root@the-server
Connection closed by 111.112.113.114

When running SSH with -vvv, SSH stops on 'expecting SSH2_MSG_KEX_DH_GEX_GROUP':

...
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes256-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP   <-- blocks 1 or 2 minutes
Connection closed by 111.112.113.114

What is happening? Last week, SSH was working just fine, from the same computer to the same server. Nothing has changed except that today I'm in a coworking center.

2 Answers 2

2

This:

ifconfig wlan0 mtu 576
(and then try ssh ... again)

solved the problem for me.

The problem was, as far as I've understood, that TCP packets got fragmented and some intermediate firewall dropped all but the very first packet. By reducing the maximum transfer unit (mtu), fragmentation can be avoided.

You can try with e.g. 1000 or 1472 instead of 567, but >= 1500 (the default I think) probably won't work.

Details here: http://www.snailbook.com/faq/mtu-mismatch.auto.html

1
  • Normally this is avoided by path MTU discovery – if any intermediate hop receives a too large packet, it returns an ICMP "Fragmentation Needed" error. Unfortunately, some networks break this by completely blocking ICMP... Sep 22, 2014 at 15:38
1

The ifconfig command suggested by @KajMagnus will only resolve the issue until the next time networking is restarted. To make the fix permanent under CentOS7 (or Red Hat 7), add

MTU=576

to the /etc/sysconfig/network-scripts/ifcfg-<NIC_ID> file for the relevant network interface, then restart networking:

sudo systemctl restart network

This will configure the network to have the correct MTU such that ssh will continue to work after a reboot.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .