Connection stalls at debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

[mathew]

On Mon Feb 09 2015 at 1:23:37 PM Petr Lautrbach <plautrba at redhat.com> 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
affected.


> 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 zip.com.au> 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?

Thanks,


mathew