Connection stalls at debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

[Darren Tucker]

On Mon, Feb 9, 2015 at 4:50 PM, mathew <meta at pobox.com> wrote:
[...]
>
> Connections to other servers across the same VPN, using the same OpenSSH
> versions, succeed.
>

The ciphers offered by a given version of OpenSSH can also vary based on
the version of OpenSSL they were compiled against.


> 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?
>

It depends.


> 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?
>

No, but the size of the packets sent before that point can be small enough
to not trigger MTU problems.

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

What's -m?  my netstat doesn't have it.


> 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?
>

There's 3 things that get negotiated: key exchange algorithms
(KexAlgorithms), message authentication codes (MACs) and encryption ciphers
(Cipers).  These vary by SSH implementation and version (and in the case of
OpenSSH, the version of libcrypto too).  In OpenSSH, the cipher selected
also influences the size of the Diffie-Hellman group requested (this is
controlled by the client, and was increased in a recent OpenSSH release)

Try:

ssh -vvv -o KexAlgorithms=diffie-hellman-group14-sha1 yoursever
ssh -vvv -o Ciphers=aes128-ctr yoursever

In particular, make a note of this line in the debug output:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent

This is the lower, preferred and upper sizes requested.  Exactly which size
gets sent will depend on the content of the servers "moduli" file.

debug2: bits set: 1531/3072

The 2nd number is the size the server actually sent (you'll probably need
to either run the server in debug mode or kick its loglevel to debug2 to
see this for the failure case, though, since it's not making it through).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.