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

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 281 views

SSH fails when the server's chosen Diffie-Hellman Group Exchange modulus falls outside the bounds the client requested. Fix by aligning client GEX size limits or regenerating the server's /etc/ssh/moduli.

Quick fix

Fixes ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group out of range

ssh -vv username@hostname
  1. Confirm DH-GEX is the negotiated key exchange
  2. See which algorithms the server actually supports
  3. Prefer a fixed-group key exchange (recommended fix)
  4. If group exchange is required, widen or align the client's GEX bounds
ssh — error
ssh -vv username@hostname
ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group out of range

What this error means

The "DH GEX group out of range" error occurs during SSH's Diffie-Hellman Group Exchange (DH-GEX) negotiation. With DH-GEX key exchange (the `diffie-hellman-group-exchange-*` algorithms), the client doesn't ask for a fixed prime; instead it sends the server a requested size as a triple of bit-length bounds: a minimum, a preferred ("want"), and a maximum. The server then looks in its `/etc/ssh/moduli` file and picks a prime (modulus) that fits inside those bounds. If the server cannot find a modulus that lies within the client's requested `[min, max]` range, the connection aborts with this fatal error. This is fundamentally a mismatch between what the client will accept and what the server has available in its moduli file — not simply "the server is too old." Modern OpenSSH clients default to a minimum of 2048 bits, so they reject a server that can only offer 1024-bit groups. Conversely, a hardened or stripped-down server whose `/etc/ssh/moduli` contains only very large primes (or no suitable size) can fail to satisfy a client that requests a smaller or differently-bounded range. The error is specific to the *group-exchange* family; fixed-group algorithms such as `diffie-hellman-group14-sha256` carry their prime built-in and never trigger this particular failure. The correct resolution is to bring the two sides into an overlapping, still-secure range — by adjusting the client's GEX bounds, by having the client fall back to a fixed-group algorithm both sides support, or (best) by regenerating the server's moduli file with appropriately sized, modern primes. Reaching for broken 1024-bit groups or DSA host keys is neither necessary nor safe.

Typical symptoms

  • SSH connection aborts immediately during key exchange with a fatal error mentioning 'DH GEX group out of range'
  • Verbose output (ssh -v) shows the failure right after the client and server agree on a diffie-hellman-group-exchange-* key exchange method
  • Other clients with different default GEX bounds (e.g. an older ssh, PuTTY, or a Java/JSch app) connect to the same host while your client fails — or vice versa
  • The same client connects fine to other hosts, isolating the problem to one server's moduli file
  • Switching the key exchange to a fixed-group algorithm such as diffie-hellman-group14-sha256 lets the connection succeed

Common causes

  1. The server's /etc/ssh/moduli file contains no Diffie-Hellman prime whose size falls within the bit-range the client requested (most common cause).
  2. The server's moduli file only offers small (e.g. 1024-bit) groups while the modern client demands a 2048-bit minimum, so no group satisfies both sides.
  3. A hardened or stripped-down server had its moduli file edited or replaced so that only very large (or too few) primes remain, leaving a gap that the client's requested range cannot match.
  4. A client or library with unusual or outdated GEX bounds (some old SSH clients, embedded tools, or older Java JSch versions) requests a min/max window the server cannot fill.
  5. Connecting to legacy network appliances or routers whose built-in SSH ships a minimal moduli file that no longer overlaps with modern client defaults.

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

1Confirm DH-GEX is the negotiated key exchange

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

bash
ssh -vv username@hostname

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

bash
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.

2See which algorithms the server actually supports

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

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

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

bash
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.

3Prefer a fixed-group key exchange (recommended fix)

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:

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

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

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

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

bash
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.

4If group exchange is required, widen or align the client's GEX bounds

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:

bash
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:

bash
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
5Fix it properly on the server: regenerate /etc/ssh/moduli

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:

bash
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:

bash
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.

6For embedded devices or appliances, prefer an upgrade or modern algorithm

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.

7For Java/JSch applications, update the library

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

bash
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:

xml
<!-- 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.

Advanced notes

How DH-GEX bounds work: With the diffie-hellman-group-exchange-* methods the client sends three values — minimum, preferred, and maximum modulus size in bits (RFC 4419). The server consults /etc/ssh/moduli and returns a safe prime whose length lies within [min, max]. The fatal "DH GEX group out of range" is raised by OpenSSH (in kexgexc.c on the client) when the server's selected modulus size violates the requested bounds, or when the server has no qualifying prime. Modern OpenSSH clients default to a 2048-bit minimum and an 8192-bit maximum; older clients used a 1024-bit minimum, which is why behavior differs across client versions against the same server.

Why not just force weak crypto: Setting diffie-hellman-group1-sha1 pins a fixed 1024-bit Oakley Group 2 prime that is considered broken against well-resourced adversaries (cf. the Logjam research), and ssh-dss (DSA) host keys are disabled by default since OpenSSH 7.0 and have nothing to do with key exchange — adding them cannot fix a KEX error. Neither is an appropriate remedy.

Preferred algorithms overall: Where both sides support it, curve25519-sha256 (X25519 ECDH) is the modern default — fast, secure, and immune to this moduli-file problem because it uses no negotiated prime at all. Fixed-group diffie-hellman-group14-sha256 and diffie-hellman-group16-sha512 are good fallbacks. Reserve any group-exchange SHA-1 variant for un-upgradeable legacy hardware only, scoped per-host.

Frequently asked questions

What does "ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group o" mean?
The "DH GEX group out of range" error occurs during SSH's Diffie-Hellman Group Exchange (DH-GEX) negotiation. With DH-GEX key exchange (the diffie-hellman-group-exchange- algorithms), the client doesn't ask for a fixed prime; instead it sends the server a requested size as a triple of bit-length bounds: a minimum, a preferred ("want"), and a maximum. The server then looks in its /etc/ssh/moduli file and picks a prime (modulus) that fits inside those bounds.
How do I fix "ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group o"?
SSH fails when the server's chosen Diffie-Hellman Group Exchange modulus falls outside the bounds the client requested. Fix by aligning client GEX size limits or regenerating the server's /etc/ssh/moduli.
What causes "ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group o"?
The server's /etc/ssh/moduli file contains no Diffie-Hellman prime whose size falls within the bit-range the client requested (most common cause). The server's moduli file only offers small (e.g. 1024-bit) groups while the modern client demands a 2048-bit minimum, so no group satisfies both sides. A hardened or stripped-down server had its moduli file edited or replaced so that only very large (or too few) primes remain, leaving a gap that the client's requested range cannot match.
Is the "ssh_dispatch_run_fatal: Connection to hostname port 22: DH GEX group o" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading