How to fix ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group out of range in SSH

Run a verbose SSH connection and look at which key exchange method was selected just before the failure:

ssh -vv username@hostname

In the output, find the lines showing the negotiated algorithm, for example:

debug1: kex: algorithm: diffie-hellman-group-exchange-sha256

If the chosen kex is one of the diffie-hellman-group-exchange-* algorithms and the connection then dies with "DH GEX group out of range," you've confirmed the problem is a group-exchange bounds mismatch. If a non-GEX algorithm is selected, this article does not apply.

Enumerate the server's offered key exchange algorithms so you know what you can safely fall back to:

ssh -vv username@hostname 2>&1 | grep -iE 'kex|server-sig-algs'

If you have nmap, you can fingerprint the SSH service directly:

nmap --script ssh2-enum-algos -p 22 hostname

Note whether the server offers a modern fixed-group algorithm such as diffie-hellman-group14-sha256 or diffie-hellman-group16-sha512, or only the group-exchange variants. This determines which fix in the next steps applies.

The cleanest client-side fix is to avoid group exchange entirely and use a strong fixed-group algorithm, which carries its own vetted prime and cannot fall "out of range." Most servers from the last several years support this:

ssh -o KexAlgorithms=+diffie-hellman-group14-sha256 username@hostname

If the server is newer, prefer an even stronger group:

ssh -o KexAlgorithms=+diffie-hellman-group16-sha512 username@hostname

To make this permanent for just that host, add it to ~/.ssh/config:

Host legacy-server.example.com
    KexAlgorithms +diffie-hellman-group14-sha256

Using + appends the algorithm to your client's default list rather than replacing it, so your secure defaults (such as curve25519-sha256) are still tried first.

If the server only offers diffie-hellman-group-exchange-* algorithms, keep using group exchange but make sure your requested size range overlaps what the server's moduli file can provide. OpenSSH does not expose the min/max directly as a single option, but you can re-enable the SHA-256 group-exchange variant (some hardened clients disable it) and let the negotiation proceed:

ssh -o KexAlgorithms=+diffie-hellman-group-exchange-sha256 username@hostname

If your client's default minimum (2048 bits) is higher than anything the server can offer and you cannot change the server, the supported and still-acceptable group-exchange fallback is the SHA-256 variant above combined with the fixed-group fix from Step 3. Avoid the SHA-1 group-exchange variant unless absolutely unavoidable; if you must use it temporarily against an un-upgradeable device, scope it to a single host in ~/.ssh/config and treat it as a stopgap:

Host ancient-appliance.example.com
    # Last-resort fallback for a device that cannot be upgraded.
    # SHA-1 GEX is weaker than the SHA-256 variant above; prefer Step 3.
    KexAlgorithms +diffie-hellman-group-exchange-sha1

The durable fix is on the server side. The error means the moduli file lacks primes in a size the client requests, so regenerate it with modern, appropriately-sized groups. On the SSH server (requires admin access), generate fresh candidates and screen them:

ssh-keygen -G /etc/ssh/moduli.candidates -b 3072
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.candidates
sudo mv /etc/ssh/moduli.safe /etc/ssh/moduli
sudo systemctl restart ssh   # or 'sshd' depending on the distro

On recent OpenSSH (9.x), the generation/screening is combined:

ssh-keygen -M generate -O bits=3072 /etc/ssh/moduli.candidates
ssh-keygen -M screen -f /etc/ssh/moduli.candidates /etc/ssh/moduli.safe
sudo mv /etc/ssh/moduli.safe /etc/ssh/moduli

Keep moduli at 3072 bits or larger. Never delete the moduli file or populate it with 1024-bit primes to "fix" the error — that weakens every group-exchange connection to the server.

If the remote host is a network switch, router, firewall, or other appliance with a built-in SSH server you cannot edit, first check the vendor for a firmware update — most current firmware supports diffie-hellman-group14-sha256 and modern host keys, which removes the need for any workaround.

Until then, use the fixed-group fallback from Step 3 (diffie-hellman-group14-sha256), scoped to that single host in ~/.ssh/config. Document the entry so it can be removed once the device is upgraded. Resist forcing 1024-bit fixed groups (diffie-hellman-group1-sha1) or DSA host keys (ssh-dss): the former is cryptographically broken, the latter is disabled by default in modern OpenSSH and is unrelated to this key-exchange error.

Java SSH clients can hit this error when an old library uses GEX bounds the server can't satisfy. Check your version:

grep -i jsch pom.xml        # Maven
grep -i jsch build.gradle   # Gradle

The original JSch (com.jcraft:jsch) is unmaintained; prefer the maintained fork or a modern library:

<!-- Maintained JSch fork (Maven) -->
<dependency>
    <groupId>com.github.mwiede</groupId>
    <artifactId>jsch</artifactId>
    <version>0.2.17</version>
</dependency>

Alternatively use Apache MINA SSHD (org.apache.sshd:sshd-core), which is actively maintained and negotiates modern key exchange algorithms by default, sidestepping GEX bound mismatches.