ssh-rsa deprecation.OpenSSH 8.2 was released on February 14, 2020. It introduced FIDO/U2F-backed SSH key types and warned that the ssh-rsa signature algorithm would be disabled in a future release because it depends on SHA-1. The critical migration detail is that ssh-rsa names an RSA/SHA-1 signature scheme; it does not mean every RSA key must be thrown away.
This guide replaces the old release-news page with a durable explanation of FIDO-backed keys, resident credentials, RSA/SHA-2 compatibility, and a safer way to inventory legacy SSH dependencies before removing weak algorithms.
The 8.2 release notes contain two developments that aged very differently but remain connected operationally. First, OpenSSH added native support for FIDO/U2F authenticators through new security-key-backed public key types. Second, the project warned that the ssh-rsa signature algorithm would be disabled by default in a future release because practical SHA-1 collision attacks had made continued dependence on SHA-1 increasingly difficult to justify.
The release also removed ssh-rsa from accepted certificate-signature algorithms and changed new RSA-key certificate signing to use rsa-sha2-512 by default. It removed diffie-hellman-group14-sha1 from the default key-exchange proposal as part of the same broader move away from SHA-1-era defaults.
For modern operators, the lesson is not “OpenSSH 8.2 is current software.” It is the opposite: use the release as a historical turning point, then evaluate today's actual client/server versions and configured algorithms. The durable migration concept is to separate key material, signature algorithms, host-key algorithms, certificate authorities, and authentication policy rather than treating “RSA” as one switch.
OpenSSH 8.2 added the ecdsa-sk and ed25519-sk key types. The -sk suffix identifies security-key-backed credentials. A key generated with a supported FIDO authenticator uses the hardware device during signing, and the release notes describe user presence—typically a physical touch—as the default authorization behavior.
ssh-keygen -t ed25519-sk
# or, depending on authenticator support:
ssh-keygen -t ecdsa-sk
The operational value is different from simply encrypting a private-key file with a passphrase. A copied local key file is not enough to authenticate if the signing operation still depends on the physical authenticator. That can reduce the value of workstation file theft, but it does not eliminate endpoint compromise, session theft, malicious forwarding, weak server authorization, or account-recovery risks.
FIDO2-capable tokens can support resident credentials. OpenSSH 8.2 documented resident-key generation and retrieval so a credential can be made portable without carrying the usual key-handle file between machines. That convenience changes the threat model: if more of the credential state can be recovered from the token, loss of the token matters more. Protect authenticators with an appropriate PIN/user-verification policy and maintain a deliberate recovery process.
OpenSSH supports options that relax the default touch requirement for some security-key credentials. Do not disable user presence merely because automation becomes easier. If a workload needs non-interactive credentials, design that identity separately and constrain it with service-account scope, network boundaries, command restrictions, short lifetimes, or workload identity mechanisms rather than weakening a human administrator credential by default.
ssh-rsa is an RSA/SHA-1 signature algorithm, not a synonym for every RSA key.The OpenSSH 8.2 release notes explicitly list rsa-sha2-256 and rsa-sha2-512 as better alternatives. Those algorithms can use the same RSA key type while replacing SHA-1 with SHA-2. OpenSSH has supported the RSA/SHA-2 signature algorithms since 7.2 and can use them automatically when both client and server support them.
This distinction prevents a lot of unnecessary emergency key rotation. An inventory that sees an RSA public key and concludes “deprecated” is too coarse. The correct question is which signature algorithm is actually negotiated or required by the client, server, certificate authority, appliance, library, and configuration.
ssh-rsa for RSA signatures.Record SSH server versions, supported host keys, accepted user-key algorithms, certificate-authority behavior, system crypto policy, configuration includes, jump hosts, bastions, and vendor support status. Separate internet-facing administrative endpoints from internal automation endpoints because the upgrade risk and exposure differ.
Include administrator workstations, CI runners, backup systems, configuration management, file-transfer jobs, network automation, monitoring, vendor support tools, legacy Java/.NET/Python libraries, and embedded controllers. A single forgotten client can turn a safe algorithm cleanup into an outage.
Use verbose client logs, server logs, configuration inspection, and controlled test connections to determine which algorithm is actually used. Do not re-enable ssh-rsa globally because one legacy endpoint fails; identify the dependency and scope any temporary exception narrowly.
Every legacy exception should name the system owner, reason, compensating controls, upgrade path, review date, and expiration target. Compatibility flags without an owner become permanent weak defaults.
rsa-sha2-256/512 where RSA keys remain necessary.ssh-rsa, constrain the exception to that host/path and document removal rather than reopening it globally.Primary sources: OpenSSH 8.2 release notes and the current OpenBSD/OpenSSH ssh-keygen manual.
Follow the next implementation topic without returning to search.
Reduce remote-access attack surface through identity, device posture, segmentation, application-level access, hardened VPNs, and ZTNA
Continue readingGovern identity lifecycle, authentication, federation, privileged access, service identities, access review, and identity evidence
Continue readingImprove developer workflows without losing governance
Continue readingUse the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.