SSH: DH_GEX group out of range

Question

We recently applied a vendor-supplied patch for OpenSSH. This patch disabled a few key exchange protocols in response to the recent Logjam attack. After applying this patch, we have a few vendors with which we have not been able to exchange files via sftp because the connection negotiation is failing (likely due to the deprecated key exchange algorithms).

I would just like to verify a couple of things we are seeing before talking to our vendors. Here is a sample SSH session with one of the problem vendors (line numbers added):

# ssh -vv [email protected]
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
24 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
25 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,[email protected],zlib
28 debug2: kex_parse_kexinit: none,[email protected],zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`

So during the key exchange negotiation, the client and server exchange their lists of supported algorithms (lines 21 and 33). They agree to use the first match found in the two lists, in this case diffie-hellman-group-exchange-sha1. As I understand it, this algorithm supports a range of bit lengths that the client and server then have to negotiate. Under normal circumstances, the client and server agree on a bit length and exchange keys making use of a DH prime from the moduli file, e.g. /etc/ssh/moduli (I know this last statement is very "laymen's speak," but that is roughly the long and the short of it).

In this case, what I think I am seeing is that the bit-length negotiation is failing. On line 49, the client (me) is saying "I support bit lengths between 1536 and 8192 and want to use 3072 bits." However, the server replies back and says "I only support 1024 bits." At which point the client gives up and says "I can't talk to you." Is this a reasonable description of what is happening here?

As I understand it, the problem is entirely on the server end at this point (assuming we don't negotiate a weaker algorithm like diffie-hellman-group1-sha1). The server would have to be modified to support the larger bit lengths during the key exchange process.

I'd like to make sure I am understanding this correctly before proceeding. Input is appreciated.

Solution 1

If you want to use newer OpenSSH to connect to deprecated servers:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

Add -v if you want to see what's happening, and -o HostKeyAlgorithms=ssh-dss if it still doesn't work:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

You can also, of course, edit /etc/ssh/ssh_config or ~/.ssh/ssh_config, and add:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1    

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 mentions the following fix on Mikrotik Routerboards:

/ip ssh set strong-crypto=yes

(Noting this here because this answer also comes up on web searches when looking for a similar error message.)

If you want to use it over Git without editing your ssh_config or updating the SSH server:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository

Solution 2

It seems you have hit this bug.

Cause

A change was made to the openssh package, dealing with Diffie-Hellman Group Exchange. Previously, keys of size 1024 - 8192 could be exchanged. The minimum was raised to 1536 for added security and to avoid the "logjam" vulnerability. However, if used with some 3rd party ssh implementations which only support 1024, failure will occur. Ideally, the 3rd party ssh configuration or code should be updated to use larger key sizes.

...

You can find 3 different resolutions in the link. In situations where you don't have admin power or there is too much bureaucracy to get deeper changes, getting rid of the problematic algorithm while waiting for a SHA-2 availability in the server seemed the best option to me. You can even perform it in a user-based fashion in your $HOME/.ssh/config file.

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Comments

[Michael Hampton]

You're reading it right. What on earth is at the other end? That doesn't look like any common ssh server.

[sbrown]

No idea what the server is. We are experiencing the same issue with two different vendors, both of whom are banks. Neither server identifies itself in the session (which isn't surprising).

[Michael Hampton]

You'd think that banks would be a bit more on top of security, but alas...

[Castaglia]

Searching for "GXSSSHD_Comments" turns up comments in various SFTP client forums, which in turn seem to suggest that your server is the GXS MFT application -- very enterprisy.

[Kovalex]

I've got it on network management port of dated Sun Enterprise T2000. Thanks to answers below I managed to login in using: Ciphers aes128-cbc HostKeyAlgorithms ssh-rsa KexAlgorithms diffie-hellman-group1-sha1

[bao7uo]

this works for sftp also