The past and present life of SSH key algorithm Ed25519 and RSA, and how to use it today

Many people’s first contact with SSH starts with a line of commands:

There is nothing wrong with this command, but there is an often overlooked issue behind it: Are we talking about “RSA key type” or ssh-rsa “signature algorithm”?

These two concepts are used interchangeably in many old tutorials, leading many people to think that they are “still using old and unsafe solutions” and at the same time don’t know how to migrate, and even repeatedly step into pitfalls between new systems and old devices.

This article explains this clearly:

1. How RSA and Ed25519 came to be in the SSH world.
2. Why is everyone recommending Ed25519 today?
3. If you still have a bunch of old machines online, how should you migrate them safely?
4. What should be the default strategy for individuals and teams in 2026?

ssh-keygen -t rsa

1. Align the concepts first: there is more than one “algorithm” in SSH

Many articles discuss the SSH algorithm. In fact, there are at least four types of things in the SSH protocol:

1. Key exchange algorithm (KEX): determines how the session key is negotiated.
2. Host Key Algorithm (Host Key): How does the client confirm that “this server is itself”.
3. User authentication signature algorithm (Public Key Auth): When you log in, the client uses the private key to sign, and the server verifies the signature.
4. Symmetric encryption/MAC: How data is encrypted and integrity protected after the session is established.

The RSA and Ed25519 we are talking about today mainly fall into categories 2 and 3.

This is why you see these names appearing together:

The most commonly misunderstood ones are:

• RSA is a family of asymmetric algorithms (key types).
• ssh-rsa is the “RSA + SHA-1” signature identifier.
• “RSA key + SHA-2 signature” (rsa-sha2-256/512) is now recommended instead of ssh-rsa (SHA-1).

As long as this layer is clarified, all subsequent configurations can basically be understood.

2. The past life of RSA: why it once dominated the world

RSA has a long history. If you look at it in SSH, it can be roughly divided into several paragraphs:

1. In 1977, RSA was published publicly and became one of the most important cornerstones of modern public key cryptography.
2. From the 1990s to around 2010, RSA was almost the “default option” in various protocols.
3. The early SSH ecosystem (especially old systems and old firmware) used RSA extensively, and the ssh-rsa logo has been used for a long time.

It can dominate the mainstream for a long time for very practical reasons:

1. Mature implementation, wide library and hardware support.
2. Good compatibility, almost all systems recognize it.
3. The administrator is familiar with it, and there are many documents and tutorials.

But the problem is just as real:

1. To achieve the same security strength, RSA keys are usually larger (commonly 2048/3072/4096 bit).
2. In handshake and signature scenarios, speed and resource overhead do not dominate.
3. A large number of ssh-rsa bound to SHA-1 were deployed in the early years, and SHA-1 is no longer suitable as a long-term security baseline.

The “RSA is not safe” argument that everyone feels later is essentially saying: The old ssh-rsa (SHA-1) should no longer be used as the default; this does not mean that RSA math itself cannot be used immediately.

3. The life of Ed25519: why it became the default recommendation

Ed25519 comes from the Edwards curve system, which is very “operation and maintenance friendly” in engineering:

1. The key is short, and both the public key and the private key are lighter.
2. Fast signing and verification, with less pressure on the CPU.
3. The parameters are fixed to reduce the probability of “wrong selection of curve parameters”.
4. Mature support in modern OpenSSH and good default experience.

You can understand it as: In the specific scenario of “daily SSH login and automated operation and maintenance”, Ed25519 gives a better performance/security/availability balance point.

So in most new environments today, the default priorities are:

1. Ed25519 preferred.
2. Only use RSA if it is fully compatible (and try to use SHA-2 signatures).

4. A key watershed: ssh-rsa was eliminated by default

Many people start to study algorithm problems only when they suddenly encounter this kind of error after a certain system upgrade:

The core changes behind this are:

1. The new version of OpenSSH no longer accepts the ssh-rsa signature based on SHA-1 by default.
2. However, RSA keys can still be used, as long as rsa-sha2-256 or rsa-sha2-512 is negotiated.

This is the standard answer to the “can RSA still work?” debate:

• It works, but don’t use ssh-rsa as the default.
• The new system is based on Ed25519, with RSA as the compatibility layer.

5. Recommended baseline for 2026: How to choose between individuals and teams

The following strategy is suitable for most individual developers, small teams, and general enterprise operations.

1) User login key policy

1. The ed25519 user key is created by default.
2. Force the private key password (passphrase) and cooperate with ssh-agent.
3. Keep an extra RSA 3072/4096 key only if necessary for compatibility with older equipment.

2) Server Host Key strategy

1. Enable at least one Ed25519 host key.
2. The RSA host key can be retained for old client compatibility.
3. Deny or minimize ssh-rsa (SHA-1) signature paths.

3) Authentication and access control strategy

1. Turn off password login and use public key authentication.
2. Direct login with root password is prohibited.
3. authorized_keys does fine-grained restrictions (source IP, command restrictions, prohibited port forwarding, etc.).

4) Compliance exceptions (FIPS, etc.)

In some strong compliance environments, Ed25519 may not be an available option. When encountering this kind of scenario:

1. Enforce against an organizational compliance baseline (usually a specific curve or RSA scheme).
2. Don’t “privilege your personal preferences over audit requirements.”
3. Within compliance and compatibility constraints, try to use SHA-2 signature and least privilege policy.

6. Practical Operation 1: The client correctly generates and uses keys

1) Generate Ed25519 key (recommended)

illustrate:

1. -a 64 is the number of KDF rounds, which improves the ability of passwords to resist brute force cracking.
2. After generation, it is recommended to confirm that the permission of the private key file is 600.

ssh-keygen -t ed25519 -a 64 -C "your_email@example.com"

2) Add to agent

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

3) Server installation public key

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

4) Client ~/.ssh/config example

This configuration has only one core purpose: Make connection behavior predictable and don’t try a bunch of private keys on your machine randomly.

Host prod-main
  HostName 203.0.113.10
  User deploy
  Port 22
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ServerAliveInterval 30
  ServerAliveCountMax 3

7. Practical Operation 2: A robust template for the server sshd_config

The following example is a general security baseline. Please adjust it according to the release path and version:

After modification, it is recommended to do two steps:

Note that reload takes priority, don’t just restart lock yourself out.

# /etc/ssh/sshd_config

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey
MaxAuthTries 3

# Host keys
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Prefer modern public key signature algorithms
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

sshd -t
systemctl reload sshd

8. Migrating from an old RSA environment: a set of low-risk steps

The problem with many online environments is not “not being able to match”, but “not being able to disconnect”. It is recommended to follow the steps below to almost minimize the risk.

Step 1: Take inventory first

1. Count the SSH client versions of all servers, springboard machines, and CI nodes.
2. Find systems that still depend on ssh-rsa (usually old NAS, old switches, old distributions).
3. Identify key types for all automation tasks (Ansible, CI/CD, backup scripts).

Step 2: Add before subtracting

1. Add Ed25519 host key to the server first.
2. First add the Ed25519 user public key to the operation and maintenance account.
3. Keep the original RSA compatible path and observe it for a period of time.

Step 3: Switch default in batches

1. The client default IdentityFile is changed to Ed25519.
2. CI task keys are replaced one by one to avoid complete cutting at one time.
3. Observe the reasons for authentication failure in logs to confirm that no key services are affected.

Step 4: Close the mouth

1. Disable ssh-rsa (SHA-1) signature for new environments.
2. Make whitelist exceptions for historical island devices and do not spread the exceptions to the whole world.
3. Write exceptions into documentation and configuration management, and don’t rely on “memory operation and maintenance”.

9. Common misunderstandings and correction suggestions

Misunderstanding 1: ssh-rsa cannot be used = RSA cannot be used at all

Correction:

• The ssh-rsa (SHA-1) signature cannot be used by default.
• RSA key pairing rsa-sha2-256/512 is still available as a compatible solution.

Myth 2: As long as it is Ed25519, it is absolutely safe

Correction:

1. If the private key has no password, confusing permissions, and is distributed at will, trouble will still occur.
2. Security not only depends on the algorithm, but also on key life cycle management.

Misunderstanding 3: For compatibility, enable the old algorithm globally

Correction:

1. Only write exception configurations for specific hosts.
2. Avoid relaxing the algorithm on the global Host * to prevent the risk from spreading to all connections.

For example, to only make a temporary exception for older devices:

And delete this configuration promptly after the device is upgraded.

Host legacy-switch
  HostName 198.51.100.20
  User admin
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

10. Finally, give an executable list (just follow it)

If you want to bring your SSH system back to the correct state now, you can follow this checklist:

1. Create a new Ed25519 key and set a strong password.
2. Install the Ed25519 user public key on the server.
3. sshd_config Turn off password login and enable public key authentication.
4. Client ~/.ssh/config specifies IdentityFile and IdentitiesOnly yes.
5. Only “host-level” temporary compatibility is provided for old devices, and no global relaxation is performed.
6. Inventory and replace legacy weak configurations in CI/CD.
7. Review SSH algorithms and key policies quarterly.

If you do these 7 things, you can basically satisfy the following requirements at the same time:

1. Daily operation and maintenance are stable.
2. Better performance and experience.
3. The security baseline does not fall behind.
4. The migration process of the old system is controllable.

Conclusion

RSA’s historical status in SSH is indeed “meritorious level”; Ed25519 is a modern solution that is more suitable as the default option today.

The truly correct approach is not to emotionally “bet on only one algorithm”, but to:

1. Establish a new baseline with Ed25519.
2. Use RSA(SHA-2) for controlled compatibility.
3. Converg the exceptions to the minimum scope and continue to clean them up.

When you turn “algorithm selection” into an “auditable, migratory, and rollable” engineering practice, SSH will be truly stable.