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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.