Resolving “SSH: DH_GEX group out of range” Error in Key Exchange Negotiation


3 views

The error occurs during SSH key exchange negotiation when the client and server fail to agree on a suitable Diffie-Hellman Group Exchange (DH_GEX) parameter size. From the debug output:

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
DH_GEX group out of range: 1536 !< 1024 !< 8192

This indicates the client requested DH parameters between 1536-8192 bits (preferring 3072), but the server only supports 1024-bit groups, which falls outside the client's acceptable range.

After security patches addressing vulnerabilities like Logjam, modern OpenSSH implementations enforce stricter requirements:

  • Minimum DH group size of 2048 bits recommended
  • Deprecation of weak algorithms (group1-sha1, group14-sha1)
  • Preference for ECDH and modern exchange methods

The root cause appears to be the vendor's SSH server implementation:

debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1

The server only supports outdated DH groups and doesn't properly implement group exchange negotiation.

For temporary compatibility with legacy servers, you can modify the client configuration:

# /etc/ssh/ssh_config or ~/.ssh/config
Host legacy-server.example.com
    KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
    Ciphers aes128-ctr,aes192-ctr,aes256-ctr
    MACs hmac-sha2-256,hmac-sha2-512

Alternatively, force a specific key exchange method:

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 user@host

The proper fix requires vendor cooperation to update their SSH server:

  1. Upgrade to support modern DH groups (2048-bit minimum)
  2. Implement proper group exchange negotiation
  3. Support ECDH key exchange methods
  4. Update cryptographic primitives

For internal systems, ensure your moduli file contains sufficient group sizes:

# Generate new moduli file
ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli

While workarounds exist, be aware of the security implications:

  • 1024-bit DH groups are considered cryptographically weak
  • SHA-1 has known vulnerabilities
  • Temporary fixes should be replaced with proper upgrades
  • Consider implementing SSH certificate-based authentication

When examining the debug output (lines 49-51), we see a fundamental mismatch in DH group size negotiation:

SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
expecting SSH2_MSG_KEX_DH_GEX_GROUP
DH_GEX group out of range: 1536 !< 1024 !< 8192

The core issue stems from incompatible Diffie-Hellman Group Exchange (DH_GEX) parameters between client and server:

  • Client offers: min=1536, preferred=3072, max=8192 bits
  • Server responds: fixed 1024-bit group (below client's minimum)

The vendor's SSH implementation (GXSSSHD) appears to be using outdated cryptographic standards:

debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1

For temporary compatibility, you could modify the client configuration (/etc/ssh/ssh_config):

Host problematic-vendor-host
    KexAlgorithms diffie-hellman-group14-sha1
    HostKeyAlgorithms ssh-rsa,ssh-dss
    Ciphers aes128-ctr,aes192-ctr,aes256-ctr
    MACs hmac-sha1

For proper security, the vendor should update their SSH server to support modern key exchange methods:

  1. Upgrade to support diffie-hellman-group-exchange-sha256
  2. Generate larger modulus groups (2048-bit or larger)
  3. Update their moduli file with modern primes

To test the modified configuration:

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 \
    -oHostKeyAlgorithms=ssh-rsa \
    -vv user@host.domain.com