This error occurs when OpenSSH client and server cannot agree on Diffie-Hellman key exchange parameters. Modern OpenSSH requires minimum 2048-bit moduli, but some legacy systems only support 1024-bit keys, causing the connection to fail.
The "DH GEX group out of range" error happens during the SSH key exchange phase when the client and server negotiate cryptographic parameters for the connection. Diffie-Hellman (DH) key exchange uses mathematically generated prime numbers (moduli) of specific bit sizes. Starting with OpenSSH 7.1, the minimum accepted modulus size increased to 2048 bits for security reasons. If the remote system only supports smaller moduli (typically 1024 bits), the client rejects the connection because it falls outside the acceptable range. This is a security-driven change: smaller moduli are vulnerable to cryptographic attacks, so OpenSSH enforces stronger standards. The error typically appears when connecting to legacy devices like old network appliances, routers, or systems running outdated SSH software that hasn't been updated in many years.
First, verify what algorithms the remote SSH server supports:
ssh -v username@hostname 2>&1 | grep -i 'kex|encryption|mac'This verbose output shows the key exchange algorithms your client is offering and what the server responds with. If the server only offers old algorithms, you'll need a workaround.
You can also use nmap to fingerprint the SSH service:
nmap --script ssh2-enum-algos -p 22 hostnameSpecify an older but still reasonably secure key exchange algorithm that the legacy server might support:
ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss username@hostnameOr try the older algorithm if the above doesn't work:
ssh -o KexAlgorithms=diffie-hellman-group1-sha1 username@hostnameWarning: These older algorithms (SHA1) are less secure than modern alternatives. Only use this as a temporary workaround until the remote system is upgraded.
To make this permanent for a specific host, add it to your ~/.ssh/config:
Host legacy-server.example.com
KexAlgorithms diffie-hellman-group14-sha1
HostKeyAlgorithms +ssh-dssThe proper long-term solution is to upgrade the remote SSH server to a modern version. Contact the system administrator of the remote host and request:
1. Update OpenSSH to version 7.1p2 or later
2. Regenerate SSH host keys with stronger parameters (minimum 2048-bit DH moduli)
3. For network appliances, apply the latest firmware/security patches
Most vendors now support SHA2-based algorithms in recent firmware releases. This eliminates the need for legacy workarounds.
If you're using Java SSH clients (like JSCH), the issue is often an outdated library version:
# Check your JSCH version
grep -i jsch pom.xml # For Maven
# or
grep -i jsch build.gradle # For GradleUpdate to JSCH 0.1.54 or later, or consider switching to a more actively maintained library:
- JSch: com.jcraft:jsch:0.1.55 or later
- Ganymed SSH-2: org.ganymed:ganymed-ssh2:build-262 or later
- Apache SSHD: org.apache.sshd:apache-sshd:2.x (modern, actively maintained)
Update your dependency manager:
<!-- Maven pom.xml -->
<dependency>
<groupId>com.jcraft</groupId>
<artifactId>jsch</artifactId>
<version>0.1.55</version>
</dependency>Understanding Diffie-Hellman Key Exchange:
DH GEX (Diffie-Hellman Group Exchange) allows the client and server to negotiate a modulus size during connection setup, providing flexibility. However, OpenSSH 7.1+ requires minimum 2048-bit moduli for security. The error message often shows the specific bit ranges, like "DH_GEX group out of range: 1536 !< 1024 !< 8192", indicating the server offered 1024-bit (too small), the minimum is 1536, and maximum is 8192.
Why the change happened:
Advances in computational power and factorization algorithms (like the General Number Field Sieve) make 1024-bit keys breakable by well-resourced attackers. The security community recommends minimum 2048-bit keys for symmetric encryption with lifespans beyond 2030. OpenSSH's stricter enforcement is part of broader industry movement toward stronger cryptography.
Modern alternatives:
If possible, negotiate modern key exchange algorithms like:
- curve25519-sha256: Based on elliptic curves, fast and secure
- ecdh-sha2-nistp256: Elliptic curve, widely supported
- These are preferred over DH-based algorithms in modern deployments
For embedded systems:
Some embedded devices (network switches, firewalls, management interfaces) have built-in SSH servers that cannot be upgraded. In these cases, the workaround is your only option unless you can replace the device. Always document such workarounds in your deployment documentation.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH