SSH Key Types: RSA, ECDSA, Ed25519

By Kokil Thapa | Last reviewed: September 2026

Choosing the wrong algorithm wastes time on lockouts and weak keys. SSH key types: RSA, ECDSA, Ed25519 are the three families OpenSSH supports for public-key authentication on Linux servers, Git hosts, and CI runners. They differ in math, minimum safe key size, performance, and how older clients behave. This guide explains each type, shows copy-paste ssh-keygen commands, and gives a practical default for production work in 2026. If you manage Ubuntu servers or Linux system administration for client sites, getting this right is baseline hygiene—not an optional hardening step.

What are SSH key types RSA, ECDSA, and Ed25519?

SSH public-key authentication proves identity with a key pair. You keep a private key on your laptop or CI secret store. The server stores the matching public key in ~/.ssh/authorized_keys. During login, OpenSSH runs a challenge–response protocol. The client signs with the private key; the server verifies with the public key. The algorithm name in your key file tells both sides which math to use.

RSA is the oldest option here. It relies on the difficulty of factoring large integers. ECDSA uses elliptic-curve discrete logarithms. Ed25519 is also elliptic-curve based, but on Curve25519 with a deterministic signature scheme. All three ship in modern OpenSSH. Your choice affects key file size, CPU cost per login, and whether a ten-year-old router or embedded device can connect.

RSA keys

RSA keys dominated SSH for two decades. A 2048-bit RSA key was the common default for years. NIST guidance now treats 2048-bit RSA as a transitional size; NIST SP 800-57 Part 1 Rev. 5 points teams toward 3072 bits or larger for long-lived identity keys. In practice, generate RSA-4096 when you need RSA at all. Public keys are bulky—often 700+ characters in authorized_keys. Signature and verification cost more CPU than Ed25519, which matters on busy jump hosts.

OpenSSH 8.8+ disabled SHA-1-based ssh-rsa host keys by default because SHA-1 is deprecated for signatures. User keys using rsa-sha2-256 or rsa-sha2-512 remain fine. If you see "no matching host key type", the client or server is negotiating old algorithms. That is a compatibility signal, not a reason to stay on weak RSA forever.

ECDSA keys

ECDSA offers smaller keys than RSA at similar strength. OpenSSH supports NIST curves P-256, P-384, and P-521 via -t ecdsa -b 256 (or 384, 521). A 256-bit ECDSA key is roughly comparable to RSA-3072 for many threat models. The catch is ecosystem trust: some engineers distrust NIST curve parameters. ECDSA also demands careful randomness during signing. A bad RNG once leaked private keys in the wild. Ed25519 avoids that failure mode with deterministic signatures.

Ed25519 keys

Ed25519 is the modern default on GitHub, GitLab, and current Ubuntu images. Keys are always 256 bits. Public keys are short—about 68 characters in base64 form. Signatures are fast on laptops and cheap on servers. RFC 8709 standardised Ed25519 for SSH. OpenSSH has supported ssh-ed25519 user keys since 6.5 (2014). Unless you hit a legacy blocker, this is the algorithm to generate today. Our earlier write-up on RSA vs Ed25519 for SSH keys walks through migration steps if you still have old RSA keys in rotation.

How do you generate RSA, ECDSA, and Ed25519 SSH keys?

OpenSSH ships ssh-keygen on Linux, macOS, and Windows with OpenSSH installed. Keys live in ~/.ssh/ by default. Protect private keys with a passphrase unless a non-interactive automation path requires otherwise—and even then, prefer hardware or agent-based flows over naked keys on disk.

Generate Ed25519 (recommended default)

ssh-keygen -t ed25519 -C "kokil@laptop-2026" -f ~/.ssh/id_ed25519

The -C comment appears at the end of the public key line. Use an email or machine label you can audit later. Passphrase entry is interactive; press Enter only if you accept the risk on that host.

Generate RSA-4096 (legacy compatibility)

ssh-keygen -t rsa -b 4096 -C "legacy-deploy-key" -f ~/.ssh/id_rsa_4096

Do not use 2048 bits for new RSA keys. Some compliance checklists still ask for RSA specifically. In those cases, 4096 is the sensible floor. For a deeper size discussion, see RSA vs ECC key sizes and trade-offs.

Generate ECDSA (only when required)

ssh-keygen -t ecdsa -b 256 -C "vendor-required-ecdsa" -f ~/.ssh/id_ecdsa

P-384 and P-521 are available via -b 384 or -b 521. Most teams never need them. If a vendor mandate mentions "ECDSA", confirm whether Ed25519 is also accepted before committing to NIST curves.

Deploy the public key safely

Copy only the .pub file to the server. Never paste a private key into email, Slack, or a ticket.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Manual install works when ssh-copy-id is unavailable:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

On production servers I maintain through Deployer and GitLab CI, each deploy user gets one Ed25519 key per machine or pipeline. Sister legal-tech sites on shared EC2—such as Translation Nepal—share the same hardening pattern: key-only auth, no password logins. Full lockdown steps live in SSH key-only authentication setup and Ubuntu SSH server setup.

Which SSH key type should you use in 2026?

Default to Ed25519 for human developers, deploy keys, and new automation. Fall back to RSA-4096 when a target system rejects Ed25519—old network gear, some legacy Java SSH clients, or antique managed hosting panels. Skip new ECDSA keys unless a third party explicitly requires that algorithm and excludes Ed25519.

Git hosting mirrors this table. GitHub, GitLab, and Bitbucket accept all three for user and deploy keys. Their docs nudge users toward Ed25519 or RSA-4096. For commit signing, SSH keys now sign Git objects directly—see sign Git commits with GPG or SSH. An Ed25519 signing key is short and quick to load in ssh-agent.

Long-lived SSH keys in CI are an operational liability. Keys leak through logs, backups, and departed employees. Where the platform allows, use workload identity instead—our guide on Deploy to AWS from GitHub Actions with OIDC shows the pattern. Keep SSH keys for servers that still need them, and rotate on a schedule.

Passphrases, agents, and tooling

A passphrase encrypts the private key at rest. Pair it with ssh-agent so you type the passphrase once per session. Generate strong passphrases with a local password generator if you do not use a manager already. Never reuse website passwords as key passphrases.

List loaded keys:

ssh-add -l

Agent forwarding extends your key to remote hosts. That convenience creates lateral movement risk if a remote box is compromised. Read SSH agent forwarding risks and alternatives before enabling ForwardAgent yes in ~/.ssh/config.

How do you configure OpenSSH to accept specific key types?

Server policy lives in /etc/ssh/sshd_config on Ubuntu and most Linux distros. Client behaviour is in /etc/ssh/ssh_config or per-user ~/.ssh/config. After edits, validate and reload:

sudo sshd -t && sudo systemctl reload ssh

The PubkeyAcceptedAlgorithms directive controls which public-key types the server accepts. OpenSSH 9.x defaults usually include Ed25519 and modern RSA signature types. Explicit hardening example:

PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Test before you lock yourself out. Keep a second session open while reloading sshd. On client machines, force Ed25519 for a host:

Host prod.example.com
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

IdentitiesOnly yes stops the client from offering every key in the agent—a common cause of "too many authentication failures". For defence in depth, combine key types policy with harden SSH on Linux servers, fail2ban and port hardening, and disable password authentication once keys work.

Inspect keys you already have

Audit existing keys before a rotation project:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
find ~/.ssh -name '*.pub' -exec ssh-keygen -lf {} \;

The fingerprint line shows bit length and algorithm type. Remove orphaned keys from authorized_keys when staff leave or laptops are retired. One key per person per purpose keeps audits simple.

What are common mistakes when choosing SSH key types?

Teams still repeat the same errors. Most are fixable in an afternoon if you catch them before a lockout or breach.

1. Generating RSA-2048 in 2026. Treat 2048 as deprecated for new identity keys. Move to Ed25519 or RSA-4096.
2. Reusing one private key everywhere. Separate keys for personal login, CI deploy, and vendor access. Compromise blast radius drops sharply.
3. Skipping passphrases on laptops. Unencrypted keys plus a stolen device equals full server access. Use a passphrase and disk encryption.
4. Pasting private keys into cloud panels. Only the public key belongs on the server. Store private material in a secret manager or hardware token.
5. Ignoring algorithm negotiation errors. Run ssh -vvv user@host and read the "Offering public key" lines. Mismatch explains most "Permission denied (publickey)" cases.
6. Leaving password auth enabled. Keys alone do not harden SSH if passwords still work. Disable after confirming key login.

On client projects I handle through support and maintenance, the incident pattern is familiar. Someone generates a key on Windows with PuTTYgen, converts formats incorrectly, and the server receives a mangled line in authorized_keys. Stick to OpenSSH native format when both ends are Linux. For mixed environments, document the exact export steps once and store them in your runbook.

Understanding how keys fit into wider trust models helps too. Public key infrastructure explained covers certificates and CAs—orthogonal to day-to-day SSH user keys, but relevant when you move to SSH certificates at scale. For tunnel use cases after auth works, see SSH tunneling and port forwarding explained.

Rotation and compliance checklist

Schedule key rotation at least annually for production deploy keys. Document who owns each key line in authorized_keys via the comment field. Pair rotation with a review of PubkeyAcceptedAlgorithms so deprecated types disappear over time.

• Inventory all keys with ssh-keygen -lf
• Generate replacement Ed25519 keys with fresh comments
• Append new public keys before removing old ones
• Test from a staging jump host
• Remove retired keys and revoke CI secrets
• Reload sshd only after validation with sshd -t

The official OpenSSH manual remains the authoritative reference for directive names and version-specific defaults. Defaults shift between distro releases; always test on your target Ubuntu version before mass rollout.

Key Takeaways

• Prefer Ed25519 for new SSH keys; use RSA-4096 only when a legacy system rejects Ed25519.
• Generate keys with ssh-keygen -t ed25519; deploy only the .pub file to authorized_keys.
• Set a passphrase, use ssh-agent, and avoid agent forwarding unless you understand the risk.
• Harden servers with PubkeyAcceptedAlgorithms, disable password auth, and keep a test session open during reloads.
• Rotate deploy keys on a schedule; prefer OIDC over long-lived SSH keys in CI where supported.
• Audit existing keys for RSA-2048 and orphaned entries before they become an access or compliance problem.

People Also Ask

Is Ed25519 more secure than RSA?

For equivalent practical strength in 2026, Ed25519 at 256 bits matches roughly RSA-3072 or higher while avoiding RSA's larger keys and slower operations. Security also depends on key handling—passphrase, storage, and rotation matter as much as algorithm choice.

Can older servers use Ed25519 keys?

Any host running OpenSSH 6.5 or newer accepts Ed25519 user keys. Very old appliances or embedded SSH stacks may accept only RSA. Test with ssh -vvv before decommissioning your RSA key.

Why do some teams still avoid ECDSA?

ECDSA on NIST curves carries historical distrust and requires high-quality randomness during signing. Ed25519 addresses both concerns with a modern curve and deterministic signatures, which is why it replaced ECDSA as the default recommendation.

How many bits should an RSA SSH key have?

Use 4096 bits for new RSA keys. Do not create 2048-bit RSA keys for long-lived production access in 2026. If you can choose freely, Ed25519 is the better default than RSA at any size.

Pick the right algorithm, then harden the whole path

SSH key types: RSA, ECDSA, Ed25519 are not interchangeable badges—they define compatibility, performance, and how you rotate access over years. Ed25519 is the right default for new work on modern Linux, Git, and Laravel deploy pipelines I run on Ubuntu. Keep RSA-4096 in your back pocket for legacy targets. Treat ECDSA as a vendor exception, not a first choice. Pair the algorithm decision with passphrase discipline, key-only auth, and regular audits. If you want help hardening production servers or migrating off weak keys across a fleet, contact us or explore Linux administration services. For related reading, start at kokil.com.np and the blog archive—or read more about how I approach infrastructure on about me and shipped deployments in the portfolio.