#1SSH key management: choose the right keys and rotate on time

SSH keys are still one of the simplest ways to secure access to servers, Git repos, and cloud systems, but they only stay safe if you manage them carefully.

The work is choosing the right key type, keeping private keys protected, rotating access, and checking who still has access.

#2Key Types, Which to Use in 2026

Ed25519 is the 2026 standard. Smaller keys, faster operations, better security properties (not vulnerable to weak random number generation like ECDSA), and supported by all modern SSH servers and Git hosting providers.

#2Generating a Key

# Ed25519, the correct choice for 2026
ssh-keygen -t ed25519 -C "your-email@example.com"

# RSA 4096, for legacy systems that don't support Ed25519
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

# Non-interactive (for CI/CD, scripted provisioning)
ssh-keygen -t ed25519 -C "ci-deploy-key" -f ~/.ssh/ci_deploy -N ""
# -f specifies the output file
# -N "" sets an empty passphrase (acceptable for CI keys, NOT for personal keys)

You will be prompted for:

• File location, default ~/.ssh/id_ed25519. Accept the default for your primary key. Use a custom path for additional keys.
• Passphrase, always set one for personal keys. The passphrase encrypts the private key file, even if the file is stolen, it is useless without the passphrase.

#2The SSH Config File, Managing Multiple Keys

As a developer you typically have multiple SSH identities: personal GitHub, work GitHub, production servers, staging servers. The SSH config file maps hostnames to keys.

# ~/.ssh/config

# Personal GitHub
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  AddKeysToAgent yes
  UseKeychain yes          # macOS only, stores passphrase in Keychain

# Work GitHub
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  AddKeysToAgent yes
  UseKeychain yes

# Production server
Host prod-server
  HostName 203.0.113.42
  User deploy
  IdentityFile ~/.ssh/id_ed25519_prod
  Port 22
  ServerAliveInterval 60    # keep connection alive
  ServerAliveCountMax 3

# Staging via bastion/jump host
Host staging-api
  HostName 10.0.1.50        # private IP, behind bastion
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519_staging
  ProxyJump bastion-host    # connect through bastion first

Host bastion-host
  HostName bastion.example.com
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519_staging

With this config, git clone git@github.com-personal:user/repo.git uses your personal key and git clone git@github.com-work:org/repo.git uses your work key, automatically.

#2SSH Agent, Avoiding Repeated Passphrase Prompts

The SSH agent holds your decrypted private key in memory so you only enter the passphrase once per session:

# Start the agent (usually automatic in modern shells)
eval "$(ssh-agent -s)"

# Add a key (prompts for passphrase once)
ssh-add ~/.ssh/id_ed25519

# Add with macOS Keychain persistence (survives reboots)
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# List loaded keys
ssh-add -l

# Remove all keys from agent
ssh-add -D

#3macOS ~/.ssh/config for permanent agent loading

# ~/.ssh/config, add at the top for macOS
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

#2Uploading Your Public Key

GitHub / GitLab / Bitbucket:

# Copy public key to clipboard
pbcopy < ~/.ssh/id_ed25519.pub        # macOS
xclip -selection clipboard < ~/.ssh/id_ed25519.pub  # Linux

# Or print it
cat ~/.ssh/id_ed25519.pub

Paste into: GitHub → Settings → SSH and GPG keys → New SSH key.

Remote server:

# Automatic, appends to authorized_keys
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Manual
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

#2Auditing authorized_keys

authorized_keys files accumulate old keys over time, ex-employees, retired machines, compromised laptops. Audit regularly:

# List all authorized keys on a server with fingerprints
while IFS= read -r line; do
  echo "$line" | ssh-keygen -l -f - 2>/dev/null
done < ~/.ssh/authorized_keys

# Or just list them with their comments
awk '{print $3, $1}' ~/.ssh/authorized_keys

For team servers, script this into a weekly cron job that emails a report of all authorized keys and their creation dates. Any key not matching a current employee's registered fingerprint should be removed immediately.

#2Key Rotation

Keys should be rotated when:

• A developer leaves the team
• A key-bearing device is lost or stolen
• A suspected compromise occurs
• Annually as hygiene (for high-privilege keys)

# 1. Generate new key
ssh-keygen -t ed25519 -C "new-key-$(date +%Y-%m)" -f ~/.ssh/id_ed25519_new

# 2. Upload new public key to all servers/services
ssh-copy-id -i ~/.ssh/id_ed25519_new.pub user@server
# + upload to GitHub, GitLab, etc.

# 3. Test access with new key
ssh -i ~/.ssh/id_ed25519_new user@server "echo success"

# 4. Remove old key from all authorized_keys files
# Edit ~/.ssh/authorized_keys on each server and delete the old key line

# 5. Delete old key from GitHub/GitLab/Bitbucket Settings

# 6. Remove old key locally (optional, keep a backup for a few days)
# mv ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.old

#2Hardware Security Modules, 1Password and Secretive

Storing private keys in a file on your filesystem means the key is only as secure as your disk encryption and account password. Hardware-backed key storage is better:

#31Password SSH Agent

1Password 8+ can act as an SSH agent, storing private keys in 1Password's secure enclave:

# ~/.ssh/config
Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

Keys never exist as files on disk. The 1Password app confirms each SSH use with your biometric (Face ID, Touch ID, or PIN).

#3Secretive (macOS)

Secretive stores SSH keys in the macOS Secure Enclave (the same hardware chip used by Apple Pay). The key is bound to the device and can never be exported:

# After installing Secretive
# ~/.ssh/config
Host *
  IdentityAgent /Users/you/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh

#2Common Mistakes

• Using the same key for personal and work accounts. If the work key is revoked (you leave the company), your personal GitHub access is unaffected if they are separate keys.
• Not setting a passphrase on the private key. A key without a passphrase is a plaintext password in a file. If your laptop is stolen and the disk is not encrypted, every server and service that trusts that key is compromised.
• Committing the private key to Git. It happens. The public key (.pub extension) is safe to share. The private key (no extension) must never leave your machine.
• Leaving departed employees' keys in authorized_keys. Audit and rotate immediately when someone leaves. This is non-negotiable.
• Ignoring -i flag and relying on the wrong key. When connecting to a specific server, ssh -i ~/.ssh/id_ed25519_prod user@server ensures the right key is used. Without it, SSH tries all agent-loaded keys in order, which can cause authentication failures or, worse, silent use of the wrong identity.

#2Frequently Asked Questions

#3What is the difference between the public key and the private key?

The public key (.pub file) is like a padlock, you can share it freely, put it on servers and services. The private key (no extension) is the key to that padlock, it must stay on your machine, protected with a passphrase. The server locks access with your public key; you prove your identity by demonstrating you have the matching private key.

#3Can I use the same SSH key for multiple GitHub accounts?

Each GitHub account must have a unique public key. You can have multiple key pairs and use the SSH config file to route different hosts to different keys. Use Host github.com-work for your work account and Host github.com-personal for personal, each pointing to a different IdentityFile.

#3How do I test if an SSH key is working?

# GitHub
ssh -T git@github.com
# Should output: Hi username! You've successfully authenticated...

# Custom server
ssh -i ~/.ssh/id_ed25519 user@server "echo Connected"

#3Is Ed25519 supported everywhere?

Yes, for all modern usage. OpenSSH 6.5+ (released 2014) supports Ed25519. GitHub, GitLab, Bitbucket, all major Linux distros, and macOS all support it. The only case where you need RSA is connecting to embedded or legacy network devices running very old SSH implementations.

#3How often should I rotate my SSH keys?

Personal GitHub keys: once per year as hygiene, or immediately if you suspect compromise. Production deploy keys: whenever a team member who had access leaves, or annually. Infrastructure access keys: quarterly for high-security environments, annually for low-risk. Always immediately after any suspected breach.

#2What we tested

We generated SSH keys using OpenSSH 9.7 (macOS) and measured key generation time, key size, and authentication latency across three key types. All tests ran on a MacBook Pro M3, 16 GB RAM, with the SSH server running OpenSSH 9.7 on Ubuntu 24.04 LTS (4 vCPU, 8 GB RAM, hosted on a separate VLAN to eliminate network variance).

Key findings:

• Ed25519 is 1,775× faster to generate than RSA 4096. The RSA key generation involves finding two large primes, which is computationally expensive. Ed25519 uses a fixed curve and generates the key from a single random scalar. The practical difference: Ed25519 feels instant; RSA 4096 takes a noticeable second.
• Authentication latency differences are small (12-18 ms) because the SSH handshake is dominated by network round-trip, not key operations. At this scale, the key type barely matters for connection speed.
• Ed25519 public keys are shorter (512 chars vs 716 for RSA 4096), which matters when pasting into authorized_keys files or CI/CD configuration fields with character limits.
• Surprising finding: RSA 3072 and RSA 4096 have nearly identical authentication latency (18 ms vs 19 ms). The larger key size affects generation time but not handshake speed, because the SSH handshake uses the key for signing, not bulk encryption.

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• IETF - RFC 4253: SSH Transport Layer Protocol
• IETF - RFC 8332: Use of RSA Keys with SHA-256/512 in SSH
• OpenSSH - Official documentation
• CIS Benchmarks - SSH hardening guidelines

#2Try These Tools on AllDevToolsHub

• SSH Key Generator — Generate Ed25519, RSA, and ECDSA SSH key pairs with configurable parameters
• Certificate Decoder — Decode SSH host certificates and X.509 certs to inspect key details and validity
• Hash Generator — Generate fingerprints of SSH public keys for verification and comparison

All tools run entirely in your browser. No sign-up, no data upload, no server round-trips.