Here’s a concise guide to the public-key algorithms (key types) you’ll see with SSH today. They apply to both user authentication keys and host keys, though the guidance for each type is similar.
What a “key type” means
- SSH uses public-key cryptography to authenticate either you (the client) or the server (host key).
- The key type/algorithm is what determines how the key is generated, stored, and how signatures are created/verified (e.g., RSA with SHA-1 vs Ed25519).
Common SSH public-key types you’ll encounter
- Ed25519 (ed25519)
- Type name you’ll see: ssh-ed25519
- What it is: Ed25519 public-key signature system based on Curve25519; designed to be fast, small, and secure with strong resistance to many attacks.
- Pros: Fast, small keys, good security properties, simple; widely recommended for new keys.
- Cons: Not as widely supported on extremely old systems; generally fine on modern servers/clients.
- Typical sizes: 256-bit curve; very strong for practical use.
- Ed448 (ed448)
- Type name you’ll see: ssh-ed448 (less common; sometimes represented as ed448)
- What it is: EdDSA on Curve448; higher security margin than Ed25519.
- Pros: Higher theoretical security margin.
- Cons: Less widely supported; performance and compatibility can be more limited on older software.
- When to use: If you need the strongest modern elliptic-curve option and all endpoints support it.
- ECDSA (elliptic-curve DSA)
- Type names you’ll see:
- ecdsa-sha2-nistp256
- ecdsa-sha2-nistp384
- ecdsa-sha2-nistp521
- What they are: ECDSA signatures using NIST curves P-256, P-384, or P-521.
- Pros: Strong security with smaller key sizes than RSA; widely supported.
- Cons: Some argue Ed25519 is simpler and safer in practice; ECDSA can be trickier to implement securely and has had higher historical configuration complexity.
- Typical sizes: 256/384/521-bit curves.
- Note: Many operators gradually migrate away from ECDSA toward Ed25519; still in use in some environments.
- RSA (rsa-sha2-256/512, ssh-rsa, ssh-dss)
- Type names you’ll see:
- rsa-sha2-256
- rsa-sha2-512
- ssh-rsa
- ssh-dss (DSA)
- What they are:
- RSA with SHA-2 (rsa-sha2-256 or rsa-sha2-512): signatures made with RSA, using SHA-256 or SHA-512.
- ssh-rsa: the historical SSH2 RSA signature method using SHA-1 (now considered weak and being phased out).
- ssh-dss (DSA): DSA with 1024-bit keys (legacy, weak by today’s standards).
- Pros/Cons:
- rsa-sha2-256/512: Good compatibility, much preferred over ssh-rsa; still requires RSA keys.
- ssh-rsa: Deprecated due to SHA-1; many servers/clients disable this.
- ssh-dss: Deprecated and typically disabled by default; not recommended.
- Guidance:
- For new keys, prefer Ed25519 or RSA with rsa-sha2-256/512 if you need compatibility with older systems.
- If you must use RSA, aim for >= 3072 bits (4096 if you want extra margin) and prefer rsa-sha2-256/512 over ssh-rsa.
- Security key variants (hardware security keys)
- Type names you’ll see (examples):
- sk-ssh-ed25519@openssh.com
- sk-ecdsa-sha2-nistp256@openssh.com
- What they are: Keys created on a hardware security key (FIDO/U2F) with a protected private key; you must physically touch the device to authenticate.
- Pros: Strong protection against key theft; phishing resistant when used with a live device.
- Cons: Requires a security key; some setups have extra friction; not all servers support them yet.
- Note: These are “sk-” prefixed variants of standard algorithms indicating a security-key-backed key.
- SSH certificates (for enterprise/CA-based setups)
- Type names you might see in authorized_keys or server config:
- ssh-ed25519-cert-v01@openssh.com
- ssh-rsa-cert-v01@openssh.com
- What they are: A certificate format that binds a public key to a set of policy constraints, signed by an SSH CA. The key itself is the standard public-key type (ed25519, rsa, etc.), but the certificate augments it with authorization data.
- Pros: Centralized signing/rotation, easier revocation, scalable enterprise auth.
- Cons: More complex to set up; requires an SSH CA on the server side.
- Notes: You still deploy keys as usual, but servers trust the CA to vouch for them.
- SSH certificates with security keys (less common, but possible)
- You may also encounter cert-type variants that combine certificate usage with security-key-backed keys (e.g., ed25519 with a cert and a sk- prefix). The exact naming varies by OpenSSH version and enterprise policy.
What to use today (practical guidance)
- For new personal keys: Ed25519 (ssh-ed25519) is the default and widely recommended.
- If you must support very old servers/workflows: RSA with rsa-sha2-256 or rsa-sha2-512 is a good compatibility choice; avoid ssh-rsa if possible.
- If you need maximum security on endpoints you control: consider Ed25519 or Ed448; pair with security key hardware if you want hardware-backed keys.
- For enterprises with a CA: SSH certificates can simplify management at scale.
- If you’re using security keys: consider the sk-… variants for hardware-backed authentication.
How to check what your system supports or uses
- On your client (OpenSSH):
- List the key types your client can use: ssh -Q key
- See what you currently use in your key files: ls -l ~/.ssh/*.pub
- Generate a new key (examples):
- ssh-keygen -t ed25519 -C “you@domain”
- ssh-keygen -t rsa -b 3072 -C “you@domain” (or -b 4096)
- SSH with a security key: ssh-keygen -t ed25519-sk -C “you@domain” (or the appropriate sk- variant for your version)
- On the server:
- Check host key algorithms in use: grep -i HostKeyAlgorithms /etc/ssh/sshd_config
- Check what PubkeyAcceptedKeyTypes is set to (older OpenSSH): grep -i PubkeyAcceptedKeyTypes /etc/ssh/sshd_config
- If you’re using SSH certificates, look for certificate options in authorized_keys and sshd_config (e.g., TrustedUserCAKeys, TrustedUserCAKeysFile).
Notes and caveats
- DSA (ssh-dss) is deprecated and usually disabled by default; avoid.
- ssh-rsa (SHA-1) is deprecated; prefer rsa-sha2-256/512 or Ed25519.
- Ed25519 is not universally supported on extremely old systems; verify compatibility if you manage legacy infrastructure.
- If you rely on older SSH clients/servers (e.g., a Windows SSH client or hardware appliances), you may need to maintain RSA (with rsa-sha2-256/512) or even ssh-rsa until they’re upgraded.
- SSH certificates and security-key (sk-*) variants are powerful but add complexity; ensure server-side policy and tooling are ready to support them.
