Comparing SSH Keys: RSA, DSA, ECDSA, or EdDSA?

An SSH key is a pair of cryptographic keys, one public and one private, used to authenticate to a remote machine over the Secure Shell (SSH) protocol without typing a password. The private key stays on your machine and proves who you are, while the matching public key sits on the server and verifies that proof.

What's worse than an unsafe private key? An unsafe public key, which is why choosing the right key algorithm matters.

The "secure" in Secure Shell Protocol (SSH) comes from the combination of hashing, symmetric encryption, and asymmetric cryptography. This guide explains how public key authentication actually works and compares the asymmetric authentication algorithms you will encounter: RSA, ECDSA, and EdDSA (Ed25519).

We will also explore how to generate a key, check its fingerprint, the challenges of key rotation, and why certificates are the modern answer once keys start to pile up. For a broader overview of these concepts, read with our article What is Cryptographic Identity?

The short recommendation, up front: use Ed25519 for almost everything, reach for RSA 3072 or 4096 only where older systems demand it, and treat DSA and ECDSA as legacy.

How does encryption work within the SSH protocol?

SSH is used almost universally to connect to shells on remote machines. The most important part of an SSH session is establishing a secure connection, which happens in two broad steps: negotiation and connection, then authentication.

SSH negotiation and connection

For an SSH session to work, both client and server must support the same version of the SSH protocol. Modern clients support SSH 2.0, as SSH 1.0 has identified flaws. After agreeing on a version, both machines negotiate a per-session symmetric key to encrypt the connection from the outside. Generating a symmetric key at this stage, paired with the asymmetric keys used in authentication, prevents the whole session from being compromised if one key is revealed.

Negotiation happens through the Diffie-Hellman key exchange, which creates a shared secret by combining one party's private key with the other's public key. These keys are different from the SSH keys used for authentication. Modern SSH implementations also support post-quantum (hybrid) key exchange (KEX), and recent OpenSSH versions enable it by default to defend against "store now, decrypt later" attacks. For more on this step, read our guide on the SSH handshake.

SSH authentication

After negotiation, a secure channel exists, but only the server has been authenticated. In most cases the client now authenticates with public-key authentication, which involves two keys: a public key and a private key.

The private key is the secret. It lives on your machine, ideally protected by a passphrase, and never leaves it. The public key is not secret at all. You can copy it to any server you want to log into, where it will land in that account's authorized_keys file. In SSH, the private key creates a digital signature over session-specific data, and the server uses the public key to verify that signature. By verifying it, the server confirms the client holds the matching private key without that key ever leaving the client. Because the private key never travels, there is no shared password to intercept or leak, which is why key-based authentication is stronger than passwords.

Unfortunately, as infrastructure grows more dynamic, SSH keys are increasingly shared or managed improperly, compromising that integrity. Learn more about SSH best practices in this guide.

What are asymmetric encryption algorithms?

What makes asymmetric encryption powerful is that a private key can be used to derive its paired public key, but not the other way around. This is core to public-key authentication. If a weak algorithm were used, a third party could derive the private key from the public key, so choosing the right algorithm is essential.

There are three classes of algorithms commonly used for asymmetric encryption: RSA, DSA, and elliptic-curve algorithms. To evaluate their strength, it helps to understand the math at the core of each.

RSA: Integer factorization

First used in 1977, the Rivest-Shamir-Adleman (RSA) algorithm rests on the belief that factoring large semi-prime numbers is hard. Given a number n = p*q where p and q are sufficiently large primes, anyone who can factor n into its components is effectively the only party who knows p and q. Those primes are necessary to create the private key, and n underlies the public key. There is a direct relationship between factor size and the time required to break it.

DSA: Discrete logarithm & modular exponentiation

The Digital Signature Algorithm (DSA) uses public/private pairs that are mathematically related, like RSA, but solves a different problem using modular exponentiation over the discrete logarithm problem. Critically, DSA uses a randomly generated number m when signing, alongside the private key k, and m must be kept private. Because DSA is constrained to older hash functions and fixed key sizes and relies heavily on high-quality randomness, it is no longer recommended for modern SSH deployments.

ECDSA and EdDSA: Elliptic curve discrete logarithm problem

Elliptic-curve algorithms also assume there is no generally efficient solution to the discrete log problem. The Elliptic Curve Digital Signature Algorithm (ECDSA) and the Edwards-curve Digital Signature Algorithm (EdDSA) use elliptic curves, where DSA uses modular exponentiation. The complexity of the elliptic-curve discrete log problem lets both achieve the same security as RSA with significantly smaller keys.

Comparing encryption algorithms

Choosing the right algorithm depends on a few criteria: implementation (can experts handle it, or must it be rolled?), compatibility (do all SSH clients support it?), performance (how long to generate a sufficiently secure key?), and security (can the public key be derived from the private key?). Lead with Ed25519 and only step away from it for a concrete reason.

RSA

Time has been RSA's greatest ally and greatest enemy. It has the widest support across SSH clients and languages and has stood the test of time, but decades of Moore's Law have pushed key bit-length upward.

Per NIST standards, 128-bit security requires a 3072-bit RSA key, whereas elliptic-curve algorithms reach the same with smaller keys. If you need RSA, generate at least 3072 bits, and 4096 for a wider margin; avoid 1024- and 2048-bit keys for new work.

DSA

DSA's nonce m is meant to be unique, but the added need for unpredictability and secrecy makes it more like a key. Ensuring true randomness is hard, and improper implementation breaks encryption: Android's Java SecureRandom once produced colliding values, exposing Bitcoin wallet keys, and reused randomness let researchers recover the private key Sony used to sign PlayStation 3 firmware. Treat DSA as obsolete, since it is fixed at 1024 bits and removed from modern OpenSSH.

ECDSA and EdDSA

The Sony and Bitcoin failures above actually involved ECDSA, an elliptic-curve implementation of DSA. ECDSA reaches 128-bit security with 256-bit keys, but it relies on the same randomness as DSA, so the only gain is speed and length, not security. EdDSA solves the same discrete log problem using a different family of curves (the Twisted Edwards Curve) and, instead of relying on a random nonce, generates one deterministically as a hash, making it collision-resistant.

Paired with Curve25519, this gives the signature scheme Ed25519, which is fast and small while staying safe by design. It has been supported in OpenSSH since 2014, so compatibility is rarely an issue on modern systems.

RSA vs. DSA vs. ECDSA vs. EdDSA

Below are the common differences between the four algorithms:

How do you generate SSH keys with RSA, DSA, ECDSA, or EdDSA?

RSA is the default key type when generated with ssh-keygen. To choose an algorithm, supply the -t flag. The example below creates an Ed25519 key and prompts for a passphrase, which encrypts the private key at rest so a stolen file alone is not enough:

$ ssh-keygen -t ed25519 -C "unique name to identify this key."

This writes the key pair: the private key (~/.ssh/id_ed25519) never leaves your computer, and the public key (~/.ssh/id_ed25519.pub) is stored in the server's authorized_keys file, most easily with ssh-copy-id user@host. If compatibility or a FIPS requirement forces RSA, generate at 4096 bits:

$ ssh-keygen -t rsa -b 4096 -C "unique name to identify this key."

After generating, check the fingerprint, a short hash of the public key used to confirm you have the right key:

$ ssh-keygen -l -f <key file>

For higher-assurance environments, hardware-backed keys (such as ed25519-sk using a FIDO2 security key) bind the private key material to a physical device so it cannot be copied off, requiring physical user presence:

$ ssh-keygen -t ed25519-sk -C "unique name to identify this key"

A hardware-backed key is phishing-resistant and gives you a hardware root of trust. For more, learn how to generate SSH keys and read How to SSH Properly.

SSH key rotation and key sprawl

Generating an SSH key is easy. Keeping track of it for the rest of its life is the part that quietly goes wrong. Static keys do not expire on their own, so they accumulate. Engineers create keys on every laptop and workstation, copy public keys into authorized_keys files across a fleet, and rarely clean any of it up. The result is key sprawl: hundreds or thousands of public keys spread across machines, with no reliable answer to "who can log into this server, and why?"

Two problems follow. First of these challenges is SSH key rotation. Replacing a key by hand means generating a new pair, distributing the new public key everywhere it is needed, and removing the old one everywhere it exists. That is tedious and easy to get wrong, so in practice rotation rarely happens and keys live for years.

The second challenge is offboarding. When someone leaves, their access should disappear, but their public keys are scattered across many authorized_keys files, and missing one leaves a working path in. A forgotten key is a standing credential an attacker would be glad to find, and over 80% of breaches involve stolen credentials.

A team of twenty engineers, each with a key on two or three machines, accessing a few hundred hosts, can easily generate thousands of public-key placements over a couple of years. No single person has the full picture, the authorized_keys files drift out of sync, and an audit question as basic as "list everyone who can reach this production database" has no quick, trustworthy answer. This is the real-world pain that static keys create, and it is why teams move toward cryptographic identity over static credentials.

Conclusion

An SSH key is a public and private key pair that authenticates you to a remote machine without a password. This means that the practical choice will almost always be between RSA 2048/4096 and Ed25519. Between these two algorithms, the trade-offs are between performance and compatibility: RSA is universally supported, while EdDSA performs much faster and provides the same security with significantly smaller keys. Generate the key, set a passphrase, check the fingerprint, and where you can, back it with hardware.

TL;DR — Just don’t use ECDSA/DSA!

Certificates are better than keys

The fix for key sprawl is to stop trusting static keys at all and issue identity instead, which is what SSH certificates do. Rather than copying a public key onto every server and hoping you can account for it later, a certificate authority (CA) signs a short-lived certificate that proves who you are, and each server is configured to trust the CA rather than a long list of individual keys. The sprawl of public keys spread across machines goes away.

Because certificates are short-lived, the problems from the previous section mostly dissolve. There is nothing to rotate by hand, since a fresh certificate is issued at each login and the old one expires on its own. Offboarding stops being a manual hunt, because access ends automatically when a certificate lapses or is revoked at the CA. And every login is tied to a named identity, so the question of who can reach a server, and why, finally has a quick and trustworthy answer.

This is the move from managing static credentials to identity-based infrastructure access. Teleport issues short-lived certificates from a central authority, enforces least-privileged access by identity and role, and records every session to an immutable audit log, so engineers reach exactly what they are authorized for and nothing is left behind to steal or forget. The same model extends to machines, workloads, and CI/CD pipelines through Teleport Machine & Workload Identity.

Ev Kontsevoy

Ev Kontsevoy is Co-Founder and CEO of Teleport. An engineer by training, Kontsevoy launched Teleport in 2015 to provide other engineers solutions that allow them to quickly access and run any computing resource anywhere on the planet without having to worry about security and compliance issues. A serial entrepreneur, Ev was CEO and co-founder of Mailgun, which he successfully sold to Rackspace. Prior to Mailgun, Ev had a variety of engineering roles. He holds a BS degree in Mathematics from Siberian Federal University, and has a passion for trains and vintage-film cameras.