Raising OpenSSH's minimum RSA key size without breaking access

OpenSSH exposes a minimum RSA size through RequiredRSASize. Its default is 1024 bits, and administrators can raise the floor on both the client and server. The setting is simple to add, but a careless change can lock out users or hosts whose keys are still valid by protocol rules and no longer accepted by policy.

The control and its boundaries

The sshd_config manual says that RSA user and host-based authentication keys below RequiredRSASize are refused. The client manual applies the same idea to user keys and server host keys. A server host key below the client limit causes the connection to terminate because the SSH key exchange cannot simply retry with a different host key.

OpenSSH introduced the directive in version 8.7. The default remains 1024 bits, and the limit can only be raised from the default. That last detail matters during deployment: an administrator who expects to lower the value temporarily to recover a connection will not get that behavior.

The directive is not an RSA algorithm policy by itself. It does not say which signature algorithms are acceptable, and it does not replace certificate principals, authorized key restrictions, or host key verification. It is one input into the authentication decision.

Find the keys before changing the floor

Build an inventory from the public keys that actually appear in authentication paths. For user access, inspect authorized_keys, certificate authorities, and any configuration management source that recreates those files. For host access, inspect the host keys on each reachable system and the known-hosts records that clients use.

Key length is visible without exposing private material:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -lf /home/deploy/.ssh/authorized_keys

RSA keys that appear in configuration are not the only concern. A key may be supplied by an identity provider, a hardware-backed SSH key, or an ephemeral CI job. Query the inventory source rather than assuming that the files on one jump host represent every client population.

Prefer algorithms that do not need a larger RSA modulus to meet the policy. Ed25519 and ECDSA host keys are common, and a 3072-bit RSA key is a practical migration target where compatibility prevents an immediate algorithm change. The important decision is to separate key rotation from the configuration change so that a failed test does not require emergency access to the same system.

Roll out on the server and client separately

Start with a non-production server and two clients: one with a known compliant key and one with a key below the new limit. Confirm the compliant client can authenticate, the weak key is rejected with the expected message, and an existing administrative session remains available. Use a second session to make the change so a configuration error does not destroy the only route back.

Apply the server setting in the appropriate Host or global context:

RequiredRSASize 3072

For clients, put the value in the user or system SSH configuration and test host key exchange as well as user authentication. A client that rejects a small server host key will fail before it reaches the user's authorized_keys.

After the canary, roll the setting to servers in one administrative group at a time. Keep a documented break-glass path that does not bypass the policy with a copied private key. If the break-glass account uses a weak key, rotate that key before raising the floor.

Monitor for silent support cases

The most common operational symptom is not a cryptographic error in a security dashboard. It is a user who cannot log in and a host that disappears from automation. Collect the server-side authentication result, the client-side key exchange result, and the key length from the inventory. Avoid asking users to paste private keys or complete host configuration into a ticket.

After the change, review SSH logs for rejected key types and for an increase in password authentication or fallback access. Those signals can expose clients that were not included in the inventory. Retire weak keys, update known-hosts records, and keep the policy review connected to the actual access paths. A minimum key size is useful when it is a maintained control, not a one-time line added to a configuration file.

References

• OpenBSD manual, ssh_config(5)
• OpenBSD manual, sshd_config(5)
• OpenSSH project, Release Notes