RSA vs DSA vs ECDSA
What are these files for? These are your host keys uniquely identifying your host. When OpenSSH is started for the first time, it will generate these keypairs. When an SSH client connects to your server, it will advertise that it wants to authenticate the host using a particular algorithm. As several are supported, OpenSSH simply generates one of each type. This allows your server to be identified with multiple types of fingerprints.
Taken from the OpenSSH man page, ssh(1):
When connecting to a server for the first time, a fingerprint of the server's
public key is presented to the user (unless the option StrictHostKeyChecking
has been disabled). Fingerprints can be determined using ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
If the fingerprint is already known, it can be matched and the key can be
accepted or rejected. If only legacy (MD5) fingerprints for the server are
available, the ssh-keygen(1) -E option may be used to downgrade the fingerprint
algorithm to match.
The files that end in .pub are not sensitive. They are transmitted to any client that attempts a connection. The files without that extension are the private keys. If those are disclosed, anyone will be able to impersonate your SSH server to any client. The private keys are used to prove to the client that the public keys being transmitted are in fact owned by the server.
- When connecting to an SSH server, a series of events take place:
- The SSH client connects to the server and advertises its preferred algorithm.
- The server sends the desired public key to the client, if it is supported.
- The client calculates the fingerprint of the public key.
- For the first connection, the public key is saved to known_hosts.
- For subsequent connections, the fingerprint is compared against the saved one.
On the first connection, the fingerprint is displayed to the user and the user is prompted to accept the fingerprint. This is known as TOFU, or Trust-On-First-Use. On subsequent connections, the fingerprint is verified silently and automatically. If there is a mismatch, the SSH client will refuse to connect and will warn the user that a MITM attack may be occurring. This behaviour ensures that all future connections are genuine as long as the first connection is genuine. A MITM attack, or the SSH server changing its host keys for whatever reason, will invalidate this and require re-authenticating.
Which files do you need? You do not need all three and you can remove any of them, but an SSH client will only be able to verify your server's fingerprint if it has a supported fingerprint stored in the known_hosts file. At a minimum, the RSA keys should be kept. Not every client supports ECDSA, and (EC)DSA has some security issues and is generally no longer recommended. There is no downside to keeping them all, though. A quick summary of the commonly available algorithms from a security perspective: RSA is well-regarded and supported everywhere. It is considered quite secure. Common key sizes go up to 4096 bits and as low as 1024. The key size is adjustable. You should choose RSA.
DSA is not in common use anymore, as poor randomness when generating a signature can leak the private key. In the past, it was guaranteed to work everywhere as per RFC 4251, but this is no longer the case. DSA has been standardised as being only 1024 bits (in FIPS 186-2, though FIPS 186-3 has increased that limit). OpenSSH 7.0 and newer actually disable this algorithm.
ECDSA is newer and is based on DSA. It has the same weaknesses as DSA, but it is generally thought to be more secure, even at smaller key sizes. It uses the NIST curves (P256). Ed25519, while not one you listed, is available on newer OpenSSH installations. It is similar to ECDSA but uses a superior curve, and it does not have the same weaknesses when weak RNGs are used as DSA/ECDSA. It is generally considered to be the strongest mathematically.
