Fix "sshd: ssh-rsa algorithm is disabled" on RHEL

In this article we will explain the RHEL-family log line sshd: ssh-rsa algorithm is disabled and decide whether your SSH logins actually need a change.

That exact message is common after RHEL 9 or RHEL 10 upgrades, but it does not by itself prove that a client offered a legacy RSA/SHA-1 signature or that your SSH session failed. On most systems the same RSA private key still works through rsa-sha2-256 or rsa-sha2-512.

Quick answer

sshd: ssh-rsa algorithm is disabled means:

• sshd detected that RSA/SHA-1 signatures (ssh-rsa) cannot be used under the current crypto policy
• It does not by itself mean SSH is broken
• RSA keys can still work with rsa-sha2-256 or rsa-sha2-512
• Ed25519 and ECDSA logins are unaffected by this particular RSA/SHA-1 restriction

First question: does SSH actually fail?

ssh -vvv user@server

Correlate the client trace with server logs:

sudo journalctl -u sshd --since today | tail -50

What "sshd: ssh-rsa algorithm is disabled" actually means

On RHEL, Rocky Linux, and AlmaLinux, OpenSSH includes a downstream patch that tests whether RSA/SHA-1 signing is available. When the crypto layer rejects SHA-1, sshd logs:

sshd: ssh-rsa algorithm is disabled

and internally marks ssh-rsa unavailable.

Important consequences:

• Seeing this line does not prove a client attempted RSA/SHA-1 authentication
• Seeing this line does not by itself mean an SSH login failed
• The per-login rejection for a bad signature is a different message, such as userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedKeyTypes [preauth]

That distinction is why this article and the userauth_pubkey guide stay separate. This page owns the exact sshd: ssh-rsa algorithm is disabled wording. The other page owns real authentication rejections.

Timeline context:

• OpenSSH 8.2 announced that RSA/SHA-1 signatures would be disabled in a future release
• OpenSSH 8.8 disabled ssh-rsa signatures by default
• RSA-SHA2 support itself dates to OpenSSH 7.2
• RHEL 9 and later also restrict SHA-1 through system-wide crypto policy, so behavior can differ from a plain upstream tarball

Ubuntu and Debian also disable ssh-rsa on modern OpenSSH, but they more often surface userauth_pubkey or no matching host key type found instead of this exact RHEL log line.

Why RSA keys can still work

An RSA key can authenticate in more than one way:

RSA key on disk
      │
      ├── ssh-rsa       → RSA + SHA-1   → disabled on RHEL 9/10 DEFAULT
      ├── rsa-sha2-256  → RSA + SHA-256 → works on modern OpenSSH
      └── rsa-sha2-512  → RSA + SHA-512 → works on modern OpenSSH

The exact log line means SHA-1 RSA signatures are unavailable. It does not mean all RSA keys are unavailable.

OpenSSH states that existing RSA keys normally do not need replacement because they can use SHA-256 or SHA-512 signatures when both sides support them.

The first field in authorized_keys may still read ssh-rsa. That names the key type, not the signature algorithm used during login.

You do not need ssh-keygen -t rsa-sha2-512. Generate a normal RSA key with ssh-keygen -t rsa, then let a modern client negotiate RSA-SHA2.

Why you may see the log when SSH still works

This is a common search intent after an upgrade: the log looks alarming, but ssh still connects.

Typical reasons:

• sshd performs the SHA-1/RSA capability check at startup or when handling new connections
• RSA-SHA2 and Ed25519 paths remain available even though ssh-rsa is marked disabled
• Your client never needed SHA-1 RSA signatures in the first place

The core insight: sshd: ssh-rsa algorithm is disabled reports policy, not a specific failed login. Confirm behavior with a real connection before you change server policy.

Check whether SSH authentication actually fails

Run a verbose login:

ssh -vvv -o BatchMode=yes -o PreferredAuthentications=publickey \
  -o IdentitiesOnly=yes -i ~/.ssh/id_rsa user@server true 2>&1 \
  | grep -E 'signing using|Server accepts|Authenticated to|Permission denied'

On a prior RHEL 10.2 lab run against a test sshd that accepted RSA-SHA2 but not legacy ssh-rsa, the same RSA key succeeded with the default client:

debug1: Server accepts key: /home/admin/.ssh/id_rsa RSA SHA256:ozOSzxM0MKVYVp8JYKmgqtvHTROUwM7kBhE8ZkuzC04 explicit
debug3: sign_and_send_pubkey: signing using rsa-sha2-256 SHA256:ozOSzxM0MKVYVp8JYKmgqtvHTROUwM7kBhE8ZkuzC04
Authenticated to server ([192.168.56.116]:22) using "publickey".

If you see signing using rsa-sha2-256 or rsa-sha2-512 and Authenticated to, no ssh-rsa workaround is required. The existing RSA key is already using SHA-2.

If you see signing using ssh-rsa and Permission denied, continue below. Also check /var/log/secure or journalctl -u sshd for userauth_pubkey on the same timestamp.

If RSA-SHA2 login already works

When ssh -vvv shows RSA-SHA2 signatures and Authenticated to, stop here.

You do not need to:

• Add PubkeyAcceptedAlgorithms to ~/.ssh/config
• Re-enable ssh-rsa on the server
• Replace a working RSA key
• Set update-crypto-policies to LEGACY

The log line may still appear. That is expected when SHA-1 RSA signatures remain disabled by policy.

If public-key authentication really fails

Work through these steps in order.

Read the exact server error

Permission denied (publickey) alone is only a summary. On the server, look for a line like:

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

That message records an actual authentication attempt with a disallowed signature. Follow the userauth_pubkey fix guide for server drop-ins, RHEL crypto-policy overrides, and RSA-SHA2 client tests.

Upgrade an old SSH client first

A common cause is an old client that cannot sign RSA keys with SHA-2 at all. Older PuTTY releases are a frequent example: upgrading to a build with RSA-SHA2 support fixes login without weakening the server.

Check what the client supports:

ssh -Q PubkeyAcceptedAlgorithms | grep rsa-sha2

Expected on a modern OpenSSH client:

rsa-sha2-256
rsa-sha2-512

OpenSSH has supported RSA-SHA2 since 7.2. If those names are missing, upgrade the SSH client before you change server policy.

One-time RSA-SHA2 test

Only if you need to prove the same RSA key works when the client is modern enough:

ssh -o PubkeyAcceptedAlgorithms=rsa-sha2-512,rsa-sha2-256 \
  -i ~/.ssh/id_rsa user@server

If that succeeds, the key is fine and the problem is the client implementation, not the key file.

For routine use on a modern client, a simple host block is enough:

Host server
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

A current OpenSSH client selects RSA-SHA2 automatically when both ends support it. You usually do not need a persistent PubkeyAcceptedAlgorithms override, because listing only RSA-SHA2 can block Ed25519 or ECDSA keys for that host later.

Use Ed25519 for new keys

When you control both ends and want a non-RSA path, add an Ed25519 key. Generate SSH keys covers types and ssh-copy-id in more detail.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C 'admin@workstation'

Install the public key with SSH key authentication steps, then connect:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@server

On RHEL systems running in FIPS mode, Ed25519 is not available. Red Hat documents that OpenSSH does not use Ed25519 keys in FIPS mode. Use an allowed RSA key with RSA-SHA2 or another FIPS-compatible algorithm instead.

Legacy client that truly requires ssh-rsa

Use this only when a device or application cannot speak RSA-SHA2 and you have confirmed the exact failure mode.

Host-key and user-authentication fixes are independent:

OpenSSH documents both together only as an example for one destination that requires RSA/SHA-1 for host keys and user signatures.

Example for user authentication only:

Host legacy-appliance
  HostName 203.0.113.50
  PubkeyAcceptedAlgorithms +ssh-rsa

Example for host-key negotiation only:

Host legacy-switch
  HostName 203.0.113.51
  HostKeyAlgorithms +ssh-rsa

The + prefix appends one legacy name without replacing the whole default algorithm list.

If fixing ssh-rsa reveals no matching key exchange method found, that is a separate stage — see SSH no matching key exchange method found.

RHEL 9/10 crypto policy and ssh-rsa

RHEL 9 and RHEL 10 apply system-wide crypto policy through OpenSSH configuration drop-ins under /etc/ssh/sshd_config.d/. The old RHEL 8 /etc/sysconfig/sshd CRYPTO_POLICY= injection is not the model for these releases.

Check the active policy:

update-crypto-policies --show

DEFAULT

Under DEFAULT, SHA-1 RSA signatures are unavailable. That is why the exact log line exists.

Two policy layers matter on RHEL:

• OpenSSH configuration — what algorithm names sshd advertises
• System crypto policy — whether SHA-1 signing is permitted at all

Adding PubkeyAcceptedAlgorithms +ssh-rsa in a late 99-* drop-in may not override Red Hat's earlier policy file. RHEL documentation places OpenSSH policy in files such as 50-redhat.conf, and overrides that must sort before it often use names like 49-crypto-policy-override.conf rather than a late 99-* file. Because sshd uses the first obtained value for many directives, drop-in order matters.

Even when OpenSSH lists +ssh-rsa, the change may not make SHA-1 usable if the crypto layer still forbids SHA-1 signatures. That is exactly what the RHEL patch reports with sshd: ssh-rsa algorithm is disabled.

Avoid update-crypto-policies --set LEGACY unless you have no narrower option. LEGACY weakens algorithms system-wide.

For the full server-side workflow on userauth_pubkey rejects, RHEL drop-in ordering, and policy subpolicies, use the userauth_pubkey fix guide. This article stops at what the exact startup log means and when RSA-SHA2 already solves the problem.

Why the log can appear repeatedly

Repeated instances may coincide with incoming connection attempts because new sshd processes perform the same capability check.

Do not conclude from this line alone that a remote client offered ssh-rsa. Correlate nearby authentication lines, source IP addresses, and your own ssh -vvv output before you change policy.

If Ed25519 or RSA-SHA2 logins succeed while the line appears, treat it as a policy notice rather than proof of a broken key.

Troubleshooting

Summary

The RHEL-family message sshd: ssh-rsa algorithm is disabled means RSA/SHA-1 signatures are unavailable under the current crypto policy. It is not proof that a client offered ssh-rsa and not proof that SSH is broken. The same RSA key normally continues to work through rsa-sha2-256 or rsa-sha2-512, and Ed25519 logins are unaffected.

Start with ssh -vvv and server logs. If you see RSA-SHA2 signatures and Authenticated to, no workaround is needed for that client. If authentication truly fails, read the exact userauth_pubkey line and upgrade old clients before you re-enable ssh-rsa. Only allow legacy ssh-rsa when a remote implementation cannot use RSA-SHA2, and treat host-key and user-auth exceptions separately.

For real per-login rejects and RHEL drop-in ordering, use the userauth_pubkey fix guide. If the failure moves to key exchange, switch to the KEX troubleshooting guide.

References

• OpenSSH Release Notes 8.2 — future deprecation of RSA/SHA-1 signatures
• OpenSSH Release Notes 8.8 — RSA/SHA-1 disabled by default; per-host HostKeyAlgorithms and PubkeyAcceptedAlgorithms examples
• ssh_config(5) — OpenBSD manual — PubkeyAcceptedAlgorithms, HostKeyAlgorithms, and + append syntax
• Red Hat security hardening — system-wide cryptographic policies — how DEFAULT affects OpenSSH on RHEL 9+
• Red Hat OpenSSH documentation — OpenSSH configuration and crypto-policy drop-ins on RHEL 9/10