SSH所用RSA、DSA、ECDSA密钥差异及使用疑问

Let's break down the three SSH host key types you've found in /etc/ssh/—I'll cover what makes each unique, how they work, and whether you need to keep all of them around.

Key Differences: RSA, DSA, ECDSA #

Each key pair uses a distinct cryptographic algorithm, with tradeoffs in security, compatibility, and performance:

• RSA: The tried-and-true workhorse of SSH encryption. It’s based on integer factorization, with typical key lengths of 2048 or 4096 bits. RSA has universal compatibility—pretty much every SSH client ever made supports it, making it a safe default for legacy systems. Your ssh_host_rsa_key is the private key (locked down with strict permissions, as it should be), and ssh_host_rsa_key.pub is the public key shared with clients.
• DSA: Once a standard for SSH, but now obsolete. It uses a fixed 1024-bit key length, which is no longer considered secure against modern attacks. Most modern SSH clients disable DSA support by default, so this key pair is mostly just leftover baggage from older setups.
• ECDSA: A modern, efficient algorithm based on elliptic curve cryptography. ECDSA keys are much shorter (e.g., 256 bits) but offer security equivalent to a 2048-bit RSA key—plus, they’re faster to generate and use, which is great for resource-limited devices like embedded systems. Compatibility is strong with all recent SSH clients, so it’s a solid choice for modern environments.

How These Keys Are Used #

All three pairs are SSH server host keys, and their core job is to verify that the server you’re connecting to is actually the one you intended (stopping man-in-the-middle attacks). Here’s the standard workflow:

1. When a client connects for the first time, the server sends its public key (e.g., ssh_host_ecdsa_key.pub) to the client.
2. The client shows you the key’s fingerprint and asks you to confirm it’s legitimate (you’d usually cross-check this with the server admin or a pre-shared fingerprint).
3. Once confirmed, the client stores the public key in ~/.ssh/known_hosts on your local machine.
4. Every subsequent connection: the server uses its private key to sign a random value, and the client uses the stored public key to verify that signature—confirming the server’s identity hasn’t changed.

The server and client will negotiate which algorithm to use based on their mutual support. Newer clients will prioritize ECDSA or RSA, while older ones might fall back to RSA (or DSA, if it’s enabled).

Should You Keep All Three Key Pairs? #

Short answer: No, you can safely ditch DSA, but keep RSA and ECDSA.

• DSA: Remove it. It’s no longer secure, and modern clients won’t use it anyway. To clean up, delete the ssh_host_dsa_key and ssh_host_dsa_key.pub files, then edit your sshd_config file to comment out any line starting with HostKey /etc/ssh/ssh_host_dsa_key, and restart the SSH daemon (sudo systemctl restart sshd on systemd-based systems, or sudo service ssh restart on older ones).
• RSA: Keep it. It’s the ultimate compatibility fallback—if you have any older clients or systems that don’t support ECDSA, RSA will ensure they can still connect securely.
• ECDSA: Keep it. It’s faster and more efficient than RSA, and all modern clients support it. It’s a great choice for reducing server load while maintaining strong security.

内容的提问来源于stack exchange，提问作者Chaminda Bandara