Connection stalls at debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

mathew meta at
Tue Feb 10 08:50:56 AEDT 2015

On Mon Feb 09 2015 at 1:23:37 PM Petr Lautrbach <plautrba at> wrote:

> It seems to be the same problem as described and discussed in this
> [1] thread.  MTU 1400 is not enough for packet sent by
> openssh-6.6.1p1-11.1.fc21 with default settings. The size of one
> of initial packets could be even 1968. Your VPN probably makes
> a fragmentation but doesn't do the correct defragmentation.

Connections to other servers across the same VPN, using the same OpenSSH
versions, succeed.

However, I've located a second server on the same subnet that's running
OpenSSH 5.9p1 -- would you expect the same problem with that version?

Seems like everything on that particular subnet/at that particular site is

> As a workaround you can set shorter lists of MACs used by your client, eg:
> $ ssh -m hmac-sha1 ...

I already checked the FAQ and tried that, but it doesn't seem to help.

% ./ssh -vvv -m hmac-sha1 docs.rtp.tecnet
OpenSSH_6.7p1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /home/meta/.ssh/config
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

On Mon Feb 09 2015 at 1:29:17 PM Darren Tucker <dtucker at> wrote:

> I'd add "if you run netstat on both ends and see "SendQ" non-zero and not
> decreasing then this is likely your problem.

With the -m parameter as above, running ss on the client, I see Send-Q go
to 1208 and then sit there until I Ctrl-C out the client, when it increases
by 1. On the server side, I see nothing. Is that plausible, that the client
would proceed all the way through to DH_GEX_GROUP without seeing any data?

Without the -m parameter Send-Q goes to 1992.

1208 bytes shouldn't need any fragmentation; I can definitely ping
unfragmented packets that large.

So I'm thinking firewall problem now, but I'm at a loss as to why OpenSSH
is triggering the problem but PuTTY isn't, given that reducing packet size
below the MTU limit doesn't seem to help. Any ideas?



More information about the openssh-unix-dev mailing list