SSH Key Types Explained RSA vs Ed25519 (and Why You Should Upgrade)

Wenn Sie ssh-keygen for the first time, the default behavior depends on your OpenSSH version. On modern systems you might get Ed25519. On older ones you still get RSA 2048. The choice matters more than most developers realize — not because one is dramatically broken, but because the differences in security margin and performance compound over years of use across dozens of servers.

Here is what each algorithm actually does and which one you should be generating in 2024.

How SSH Public Key Auth Works

The mechanics are simple. You have a key pair: a private key that stays on your machine, and a public key that you copy to any server you want to access. When you connect, the server generates a random challenge and sends it to you. Your SSH client signs that challenge with your private key. The server verifies the signature using your public key. If it checks out, you are in — no password transmitted.

The key type determines the cryptographic algorithm used for signing and verification. Different algorithms have different security properties, key sizes, and performance characteristics.

RSA: The Original Standard

RSA is the algorithm that most people picture when they think of SSH keys. It has been part of OpenSSH since the beginning and is supported on essentially every SSH server in existence.

RSA security comes from the difficulty of factoring large numbers. The “bit size” is the size of the modulus — a very large number that is the product of two secret primes. As computing power increases, safe key sizes have grown over time.

• 1024-bit RSA: Broken. Do not use. NIST deprecated it in 2013.
• 2048-bit RSA: The current minimum. Considered secure through at least 2030 by most estimates. OpenSSH’s default if you do not specify otherwise.
• 4096-bit RSA: A larger safety margin. Signing is noticeably slower, especially on lower-powered devices like Raspberry Pis or embedded systems. For most developers, the practical difference on a laptop is barely perceptible, but it adds up if you connect to many servers or use agent forwarding heavily.

Generate an RSA key:

# Minimum acceptable — 2048-bit RSA
ssh-keygen -t rsa -b 2048 -C "your@email.com"

# Better safety margin — 4096-bit RSA
ssh-keygen -t rsa -b 4096 -C "your@email.com"

Der -C flag is just a comment appended to the public key — it does not affect security but helps you identify which key is which when you have several.

ECDSA: Elliptic Curve, Smaller Keys

ECDSA uses elliptic curve cryptography instead of integer factorization. The security model is different, and equivalent security levels require much smaller key sizes. An ECDSA key with a 256-bit curve provides roughly the same security as a 3072-bit RSA key.

OpenSSH supports three ECDSA curves: P-256, P-384, and P-521 (the number is the curve size in bits).

# ECDSA with P-256 curve (256-bit)
ssh-keygen -t ecdsa -b 256 -C "your@email.com"

# ECDSA with P-521 curve (521-bit, maximum)
ssh-keygen -t ecdsa -b 521 -C "your@email.com"

The catch: the NIST curves used by ECDSA (P-256, P-384, P-521) were generated with a process that has never been fully explained by NIST, and some cryptographers have raised concerns about potential backdoors or weak parameters. There is no known practical exploit, but Ed25519 uses a different curve (Curve25519, designed by Daniel J. Bernstein) with fully transparent parameters and a much cleaner security proof. If you are already switching away from RSA, there is little reason to stop at ECDSA.

Ed25519: The Modern Default

Ed25519 is an Edwards-curve Digital Signature Algorithm using Curve25519. It has been available in OpenSSH since version 6.5 (released in January 2014) and should be your default choice today.

What makes it better:

• Geschwindigkeit: Ed25519 signature generation is significantly faster than RSA 4096. For everyday SSH use this is imperceptible, but it matters for scripts that open many connections or services that do a lot of key operations.
• Sicherheit: 256-bit keys provide approximately 128 bits of security strength. That is well beyond any known attack for the foreseeable future.
• No weak-key issues: RSA requires careful generation to avoid weak primes. Ed25519 has no analogous pitfall — any random 256-bit private key produces a valid keypair.
• Transparent design: Curve25519 was designed with fully public parameters and a clear security proof, which avoids the trust questions around NIST curves.
• Smaller keys: An Ed25519 public key is 68 characters in the authorized_keys line. An RSA 4096 key is over 700 characters.

Generate an Ed25519 key:

ssh-keygen -t ed25519 -C "your@email.com"

There is no -b flag needed — the key size for Ed25519 is fixed at 256 bits by the algorithm itself.

You can generate multiple key types quickly using the SSH-Schlüsselgenerator tool if you want to compare the output formats side by side.

DSA: Deprecated, Disabled, Gone

DSA (Digital Signature Algorithm) is disabled by default in OpenSSH 7.0 (released 2015) and later. It only supports 1024-bit keys, which is below the minimum security threshold. If you still have DSA keys somewhere, replace them. There is no reason to generate new DSA keys under any circumstances.

Comparison at a Glance

Algorithmus	Schlüsselgröße	Security Strength	Geschwindigkeit	Use?
DSA	1024-bit	Broken	—	Niemals
RSA 2048	2048-bit	~112-bit	Medium	Minimum acceptable
RSA 4096	4096-bit	~140-bit	Slower	Good if you need RSA
ECDSA P-256	256-bit curve	~128-bit	Schnell	Acceptable
Ed25519	256-bit curve	~128-bit	Fastest	Empfohlene

Managing Multiple Keys with ~/.ssh/config

As soon as you start using different keys for different servers — one for work GitHub, one for a personal server, one for a client’s deployment target — the ~/.ssh/config file becomes essential. Without it, you end up specifying -i ~/.ssh/specific_key every time you connect.

A basic config file structure:

# ~/.ssh/config

# Default settings for all hosts
Host *
    AddKeysToAgent yes
    IdentitiesOnly yes

# Personal GitHub account
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github_personal

# Work GitHub account
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github_work

# Production server
Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

# Staging server (jump through bastion)
Host staging
    HostName 10.0.1.50
    User ubuntu
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_staging

Host bastion
    HostName bastion.example.com
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_bastion

With this config, you connect to production with ssh prod anstatt ssh -i ~/.ssh/id_ed25519_prod -p 2222 deploy@203.0.113.10. The two-GitHub-account setup using Host github-work with a different alias is a common pattern — you use git remote set-url origin git@github-work:org/repo.git to tell git to use the work key for that repo.

Der IdentitiesOnly yes directive tells SSH to only offer the keys explicitly listed in IdentityFile for that host, instead of trying everything in your agent. This prevents unexpected auth failures when the server limits authentication attempts.

For teams managing many hosts with complex jump chains and per-service keys, the SSH-Konfigurationsdatei-Generator can scaffold the Host blocks quickly without having to memorize every directive name.

GitHub and GitLab Support

Both GitHub and GitLab have supported Ed25519 keys for years. If you are still using RSA keys for Git operations, switching is a two-step process: generate a new Ed25519 key, add the public key to your GitHub/GitLab account settings, and update your SSH config to use the new key. You can keep the old RSA key active during the transition.

# Generate new Ed25519 key for GitHub
ssh-keygen -t ed25519 -C "github-personal" -f ~/.ssh/id_ed25519_github

# Copy the public key to clipboard (macOS)
pbcopy < ~/.ssh/id_ed25519_github.pub

# Or print it to copy manually
cat ~/.ssh/id_ed25519_github.pub

# Test the connection after adding to GitHub
ssh -T git@github.com

Migrating Existing RSA Keys

There is no in-place conversion from RSA to Ed25519 — you generate a new keypair and distribute the new public key. A practical migration looks like this:

• Generate the new Ed25519 key with a clear filename: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_main
• Add the new public key to each server's ~/.ssh/authorized_keys (leave the old RSA key in place for now)
• Update your ~/.ssh/config to prefer the new key
• Verify you can log in using the new key on each server
• Remove the old RSA public key from authorized_keys once confirmed

Do not delete your old private key until you have verified every server has been updated and you can still access all of them.

Das könnte Ihnen auch gefallen