Fix SSH "Bad server host key: Invalid key length" Error

The SSH error Bad server host key: Invalid key length usually means the server is using an RSA host key that your SSH client considers too small. This often appears after upgrading RHEL, Fedora, or OpenSSH, even though nothing changed on the remote server.

There is one important exception: an old RSA key saved in your ~/.ssh/known_hosts file can produce a similar error. In this article we will first identify which case you have, then apply the correct fix.

I tested the 1024-bit server host key against both RHEL 10.2 and Ubuntu 26.04. RHEL rejected it because its client requires at least 2048 bits, while Ubuntu connected with a 1024-bit minimum. I separately reproduced the stale known_hosts failure on RHEL 10.2.

If you are not sure whether the network path works at all, run the layered port and SSH service checks in test an SSH connection before you chase host-key size alone.

Quick answer

Use this order when you choose a fix:

• Live server RSA host key is too small: replace it on the server with ED25519 or a sufficiently large RSA key
• Server already has a strong host key but the client still fails: check known_hosts before lowering RequiredRSASize
• Stale 1024-bit RSA entry in known_hosts: remove or update the cached line after you verify the new fingerprint

Quick workaround for a legacy SSH server

Many reports involve older devices or services that are difficult to upgrade, such as network switches, access points, embedded OpenWrt/Dropbear systems, and older Git or Gerrit infrastructure that still exposes a 1024-bit RSA host key.

RequiredRSASize tells the SSH client the smallest RSA key it is willing to accept. RHEL 9.1+ normally requires at least 2048 bits, so a legacy server with a 1024-bit key can be rejected. If you do not control that server, test a one-time exception:

ssh -o RequiredRSASize=1024 user@server

The next command includes StrictHostKeyChecking=no and a temporary known_hosts file only to isolate the RSA-size test in my disposable lab. You do not need those options for the normal workaround above.

I verified the flag against the lab weak server on RHEL 10.2:

ssh -o RequiredRSASize=1024 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2222 root@127.0.0.1 'echo WORKAROUND_OK'

WORKAROUND_OK

When that works, restrict the exception to that host in ~/.ssh/config instead of lowering the default globally:

Host legacy-device
    HostName 192.168.1.20
    RequiredRSASize 1024

Confirm the host block with ssh -G legacy-device | grep -i requiredrsasize. This is a compatibility workaround only. If you control the server, replace the weak host key instead.

If RequiredRSASize=1024 removes this error but SSH then reports no matching host key type found or no matching key exchange method found, the RSA key-size problem is fixed. The new message is a different compatibility problem with an old SSH algorithm. Do not keep adding unrelated SSH options to fix Invalid key length. See sshd ssh-rsa algorithm is disabled for host-key algorithm limits, and SSH no matching key exchange method found when the failure moves to key exchange.

RequiredRSASize vs RSAMinSize

Current upstream OpenSSH uses RequiredRSASize. You may still find RSAMinSize in older Fedora/RHEL material and in vendor documentation for legacy devices such as OpenWrt. Fedora's OpenSSH changelog records RSAMinSize renamed to RequiredRSASize in September 2022.

Check what your installed client actually supports:

ssh -G host | grep -i requiredrsasize

If an older RPM-based client reports RequiredRSASize as an unknown option, read the local ssh_config(5) page on that host before copying an old RSAMinSize workaround from the web.

Why this suddenly happens after an upgrade

You may encounter this error even when the SSH server has not changed. The change can be on your computer instead:

• RHEL 9.1 and later enforce a 2048-bit minimum for RSA keys under the default crypto policy, so a legacy 1024-bit server host key may start failing after you upgrade the client
• An old 1024-bit server key stored in known_hosts may no longer pass the upgraded client's checks

Check which problem you have

Run these three steps before you change server keys or client policy.

1. Run:

ssh -vvv user@host

2. If the connection ends with Bad server host key: Invalid key length, check the server RSA key size and RequiredRSASize.

3. If you see ignoring hostkey: Invalid key length, check the old server key stored in ~/.ssh/known_hosts.

Read the verbose trace this way:

• Bad server host key: Invalid key length: the live server RSA host key is below your client's minimum
• ignoring hostkey: Invalid key length while SSH reads known_hosts: the saved entry is too weak even though the server's current key may be fine

Read the effective client minimum for the same target:

ssh -G user@host | grep -i requiredrsasize

In my lab, RHEL 10.2 reported 2048, while Ubuntu 26.04 reported 1024.

Look up any cached host entry before you delete it:

ssh-keygen -F hostname

Include the port in brackets when SSH does not use port 22, for example ssh-keygen -F '[192.168.56.116]:2222'.

Cause 1: Server RSA host key is too small

During SSH setup the server proves its identity with a host key. The client checks that key against ~/.ssh/known_hosts before it sends your password or user public key. Host keys live under /etc/ssh/ssh_host_* on the server; they are not the same as your personal ~/.ssh/id_rsa or id_ed25519 user key.

This failure is especially common with older switches, routers, access points, embedded devices, Git or Gerrit servers, and appliances that still expose a 1024-bit RSA host key. When the server presents that key and your client minimum is 2048, OpenSSH aborts before you reach the login prompt.

I stood up a disposable sshd on RHEL 10.2 that listens on port 2222 with only a 1024-bit RSA host key to reproduce the error:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 2222 root@192.168.56.116 exit

On RHEL 10.2:

Bad server host key: Invalid key length

The same command completed successfully from Ubuntu 26.04.

Inspect the server RSA key size when you have console access or can ask the server administrator:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

A 1024 bit count on that line confirms that the server's RSA key is below RHEL's 2048-bit minimum.

Fix the server with a stronger host key

Before you replace a host key on a shared server, keep these side effects in mind:

• Replacing an existing host key changes the fingerprint clients previously saved for that server
• Affected clients may see a host-key-change warning on the next connection
• Adding ED25519 does not necessarily replace the existing RSA identity
• Tell other users before you replace the key so they can verify the new fingerprint

First, check which host-key files already exist:

ls -l /etc/ssh/ssh_host_*_key.pub

Read the key size of each public host key:

for key in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$key"; done

Sample output from a healthy RHEL host:

3072 SHA256:wYKTeInVlp8aNmATqJ6q6FPLVz0cFB1lTvEwAgguHqk /etc/ssh/ssh_host_rsa_key.pub (RSA)
256 SHA256:m0IbDhiWVYyfyiyaMJJjBMDlxsm5n5gRMU1SgW9gV4A /etc/ssh/ssh_host_ed25519_key.pub (ED25519)

If ED25519 already exists, do not regenerate it unnecessarily. Check which host-key files sshd actually uses:

sudo sshd -T | grep '^hostkey'

This shows the effective host-key files sshd is configured to use, including defaults that may not appear explicitly in sshd_config. The sshd -T command prints the effective server configuration.

If ED25519 is missing entirely, OpenSSH documents ssh-keygen -A for generating the default host-key types that are absent:

sudo ssh-keygen -A

ssh-keygen -A only creates missing default keys. It does not replace an existing weak RSA key, so you still need a deliberate RSA rotation when the key size is 1024 bits.

Back up both halves of the existing RSA host key before replacing it:

sudo cp -a /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.bak && sudo cp -a /etc/ssh/ssh_host_rsa_key.pub /etc/ssh/ssh_host_rsa_key.pub.bak

Then generate a 3072-bit RSA key. Because /etc/ssh/ssh_host_rsa_key already exists, ssh-keygen will ask whether you want to overwrite it. Confirm the backup files above before answering y:

sudo ssh-keygen -t rsa -b 3072 -f /etc/ssh/ssh_host_rsa_key -N ''

ED25519 is a different host-key algorithm, so RequiredRSASize does not apply to it. Modern OpenSSH clients support ED25519, making it a good choice when both sides support it.

Prefer adding or enabling ED25519 when the key file does not yet exist:

sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''

Current OpenSSH normally prefers modern host-key algorithms such as ED25519 ahead of RSA. However, existing keys in known_hosts can influence host-key algorithm preference, which is another reason an old RSA entry should be checked when the server already has a newer host key.

Validate sshd syntax before you reload:

sudo sshd -t

sshd -t exits silently when the syntax is valid. Reload the service:

sudo systemctl reload sshd

On Ubuntu the unit name is often ssh instead of sshd.

Cause 2: Old weak key is cached in known_hosts

SSH remembers the identity of servers you connect to in ~/.ssh/known_hosts. If you connected to this server years ago, that file may still contain its old 1024-bit RSA key.

After an OpenSSH or crypto-policy upgrade, the client may reject that saved key before it even compares it with the server's current key. This is a real upgrade scenario: an older key can remain in known_hosts even after the server has moved to a stronger key.

I reproduced this on RHEL with a stale 1024-bit line in a test known_hosts file while the lab server used a 2048-bit RSA host key:

ssh -o UserKnownHostsFile=/tmp/stale-kh-weak-only -p 2222 root@127.0.0.1 exit

Host key verification failed.

Verbose logging shows why:

ssh -vvv -o UserKnownHostsFile=/tmp/stale-kh-weak-only -p 2222 root@127.0.0.1 exit

debug2: record_hostkey: /tmp/stale-kh-weak-only:1: ignoring hostkey: Invalid key length
debug1: Server host key: ssh-rsa SHA256:HTn3duXfOqCfoJj0JTDMyDPnFriRn4j5c19rMiubYk4
Host key verification failed.

Before you lower RequiredRSASize, check whether the server already offers a non-RSA host key you can use:

ssh -o HostKeyAlgorithms=ssh-ed25519 user@host

If that succeeds, the server already has a valid ED25519 host key. Fix the stale client entry or adjust server host-key configuration instead of weakening the RSA minimum just to keep using an obsolete RSA host key.

Ubuntu clients with a 1024-bit RequiredRSASize default may instead show the familiar host-key-changed warning because they can still parse the stale 1024-bit line for comparison. Verify the new fingerprint through the server console or another trusted source, then delete the outdated known_hosts entry.

Remove a stale known_hosts entry

After you confirm the new host key fingerprint through the server console, the server administrator, or another trusted source, remove the outdated line on the client. The generate SSH keys guide documents ssh-keygen -F and ssh-keygen -R for day-to-day known_hosts maintenance.

Look up what the client cached:

ssh-keygen -F '[192.168.56.116]:2222'

Sample output:

# Host [192.168.56.116]:2222 found: line 1
[192.168.56.116]:2222 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC6IFmF/...

Remove that entry once you trust the replacement key:

ssh-keygen -R '[192.168.56.116]:2222'

# Host [192.168.56.116]:2222 found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

Connect again with strict checking so the client learns the current key:

ssh -o StrictHostKeyChecking=accept-new -p 2222 user@192.168.56.116

RHEL crypto policies and RequiredRSASize

RHEL uses a system-wide crypto policy to decide which cryptographic settings applications such as OpenSSH are allowed to use. On RHEL, Rocky Linux, and AlmaLinux, that policy works together with RequiredRSASize.

Check the active policy:

update-crypto-policies --show

DEFAULT

Under DEFAULT, RHEL 9.1+ enforces a 2048-bit RSA minimum for OpenSSH. That is why Invalid key length host-key failures on upgraded RHEL clients often trace to policy, not a random OpenSSH bug.

Red Hat also supports a custom crypto-policy subpolicy such as min_rsa_size@openssh = 1024 when compatibility must be changed at the system-policy level. Unlike a per-host RequiredRSASize exception, however, that change can affect OpenSSH connections system-wide, so prefer a host-specific client exception when only one legacy device requires it.

If you control the server, replacing the weak host key is preferable to lowering the RSA requirement on every client.

RHEL vs Ubuntu and other distros

The minimum RSA key size depends on the distribution and local SSH configuration. In my test, RHEL 10.2 required 2048 bits while Ubuntu 26.04 used the upstream OpenSSH default of 1024 bits.

Lab result against the same legacy SSH server on port 2222:

This is why SSH may work from one computer but fail from another even when both connect to the same server. For example, an Ubuntu client may connect while a RHEL client rejects the same 1024-bit host key. If you control the server, replace the weak host key so clients do not need compatibility exceptions.

Do not regenerate your user key unless it is actually the problem

Bad server host key names the server credential. Your ~/.ssh/id_ed25519 or id_rsa key is unrelated unless verbose output points at user authentication.

Do not regenerate your user key for a host-key error:

• It changes your personal identity and forces you to redeploy public keys everywhere
• It does not change the server's RSA key size
• Sourceware and Red Hat both document cases where users replaced the wrong key because the error message sounds like a user-key problem

Troubleshooting

When the cause is unclear, run ssh -vvv from the failing client and check the size of each server host key with:

for key in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$key"; done

Summary

The SSH error Bad server host key: Invalid key length usually means the server presented an RSA host key that is smaller than your client's minimum. A related Invalid key length message can also appear in ssh -vvv when the client has an old 1024-bit server key saved in known_hosts. This is especially common after an OpenSSH or crypto-policy upgrade.

In practice:

• Start with ssh -vvv to learn whether SSH rejected the server's current host key or an old key saved in known_hosts
• If you cannot upgrade a legacy server, use RequiredRSASize 1024 only for that host
• If you control the server, replace the 1024-bit RSA host key with ED25519 or a stronger RSA key
• Check known_hosts before you lower client policy
• Do not regenerate your user key unless verbose output points at your user authentication key

References

• OpenSSH Release Notes 9.1 — RequiredRSASize introduction
• Red Hat Enterprise Linux 9.1 Release Notes — 2048-bit RSA OpenSSH minimum
• Red Hat security hardening — system-wide cryptographic policies — min_rsa_size@openssh and policy scopes
• Red Hat Bugzilla #2164016 — stale weak known_hosts key causing misleading Invalid key length
• Sourceware overseers mailing list — stale known_hosts entry after an OpenSSH or crypto-policy update
• Fedora openssh package spec — RSAMinSize renamed to RequiredRSASize (September 2022)
• ssh_config(5) — OpenBSD manual — RequiredRSASize client directive
• ssh-keygen(1) — OpenBSD manual page — fingerprint, -A, and known_hosts management options
• sshd(8) — OpenBSD manual page — HostKey directive and host key setup