SSH Keys: Best Practices for Server Access

Use ED25519 or RSA (4096); avoid password auth. Store private keys in an agent or vault; use different keys per environment. Rotate keys periodically and revoke access when team members leave.

Key type and size

• ED25519: Preferred when supported. Short keys, fast, secure. Use by default for new keys.
• RSA: Use 4096 bits if you need RSA (e.g. legacy or compatibility). Avoid 1024 or 2048 for new keys when 4096 is acceptable.
• Avoid: Password authentication for SSH. Keys (with passphrase if you want) are stronger. Disable PasswordAuthentication in sshd_config once key auth is in place.

Storage and agent

• Private keys: Never share or commit. Store on disk with restricted permissions (e.g. chmod 600). Prefer a dedicated directory (e.g. ~/.ssh) and separate keys per role or environment (e.g. prod vs staging).
• Agent: ssh-agent holds decrypted keys in memory. You unlock once (passphrase); then logins use the agent. Reduces typing passphrase and avoids leaving keys on disk decrypted. Use ssh-add to load keys.
• Vault: For teams, use a secret manager or vault (e.g. HashiCorp Vault, cloud KMS) to issue or store SSH keys (or certs). Keys can be short-lived; rotation is centralized. Integrate with ssh-agent or tooling that fetches keys on demand.

Per-host or per-environment keys

• Why: If one key is compromised, the blast radius is limited to that environment or host. Use different keys for prod, staging, and personal/dev. Some teams use one key per server (high security) or per environment (practical balance).
• Config: ~/.ssh/config lets you specify IdentityFile per host. Example: Host prod-*\n IdentityFile ~/.ssh/prod_ed25519. No need to remember which key for which host.

Rotation and revocation

• Rotate periodically: E.g. yearly or after a security event. Generate new key; add new authorized_keys entry (or replace in config management); remove old key after a grace period; then delete old key from clients.
• When someone leaves: Remove their public key from all authorized_keys (and from config management, bastions, etc.) immediately. Revoke any issued certs. If you use a vault or CA, revoke their access there too.
• Audit: Log who logged in from where (e.g. authorized_keys plus logging). Review access list periodically; remove keys for people who no longer need access.

Summary

Use ED25519 or RSA (4096); avoid password auth. Store private keys in an agent or vault; use different keys per environment. Rotate keys periodically and revoke access when team members leave.