}

SSH Key Generation and Management in 2026: ed25519, RSA, and More

Last updated: 6 min read

SSH Key Generation and Management in 2026: ed25519, RSA, and More

Last updated: March 2026

SSH keys replace password authentication with cryptographic keypairs — a private key you keep secret and a public key you share with servers. In 2026, ed25519 is the recommended algorithm for nearly all use cases: it is faster, smaller, and more secure than RSA while producing compact 68-character public keys. This guide covers algorithm selection, generating keys, deploying them to servers, managing them with ssh-agent, and rotating old keys.

Algorithm Comparison

Algorithm Key size Public key length Security Speed Recommendation
ed25519 Fixed 256-bit ~68 chars Very high Very fast Recommended for all new keys
rsa (4096-bit) 4096 bits ~724 chars High Slower Use only for legacy systems that do not support ed25519
ecdsa (256-bit) 256 bits ~140 chars High Fast Avoid — NIST curves have trust concerns in some communities
dsa Fixed 1024-bit ~604 chars Broken — Never use — disabled in OpenSSH 7.0+

Why ed25519 over RSA?

  • Smaller keys: ed25519 public keys are 68 characters; RSA-4096 keys are 724 characters.
  • Faster operations: Ed25519 signature verification is significantly faster.
  • Resistant to fault attacks: RSA is theoretically vulnerable to certain fault attacks; Ed25519 is not.
  • Same security story: Ed25519 provides approximately 128-bit security, equivalent to RSA-3072+.

The only reason to use RSA in 2026 is compatibility with very old systems (RHEL 6, ancient network devices) that do not support ed25519.

Generating an ed25519 Key

ssh-keygen -t ed25519 -C "[email protected]"

Walkthrough:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:AbCdEfGh1234567890abcdefgh [email protected]

Options explained

  • -t ed25519: Use the Ed25519 algorithm.
  • -C "comment": A comment appended to the public key. Use your email or a descriptive label. The comment does not affect security but helps identify keys in authorized_keys files.
  • -f ~/.ssh/my_key_name: Specify a custom filename instead of the default.

Custom filename example

ssh-keygen -t ed25519 -C "work laptop 2026" -f ~/.ssh/work_ed25519

This creates: - ~/.ssh/work_ed25519 — private key (keep this secret, never share) - ~/.ssh/work_ed25519.pub — public key (safe to share)

Passphrase

Always use a passphrase for keys that authenticate to production servers. A passphrase encrypts the private key on disk. If someone steals the file, they cannot use it without the passphrase.

For automation (CI/CD, scripts), you may use keys without a passphrase, but store them in a secrets manager, not plain files.

Generating an RSA-4096 Key (Legacy Systems)

When you must use RSA:

ssh-keygen -t rsa -b 4096 -C "legacy system key"
  • -b 4096: 4096-bit key. Never use 1024 or 2048-bit RSA keys in 2026.

Key Files

After generation, two files exist:

~/.ssh/id_ed25519      ← PRIVATE KEY — never share, never copy to a server
~/.ssh/id_ed25519.pub  ← PUBLIC KEY — placed on servers in authorized_keys

View your public key:

cat ~/.ssh/id_ed25519.pub

Output:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc...xyz [email protected]

Set correct permissions:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 700 ~/.ssh/

Copying a Key to a Server with ssh-copy-id

ssh-copy-id appends your public key to ~/.ssh/authorized_keys on the remote server in one command:

ssh-copy-id user@hostname

If your key is not the default filename, specify it:

ssh-copy-id -i ~/.ssh/work_ed25519.pub user@hostname

If the server is on a non-standard port:

ssh-copy-id -i ~/.ssh/work_ed25519.pub -p 2222 user@hostname

After running, test authentication:

ssh -i ~/.ssh/work_ed25519 user@hostname

Manual alternative (when ssh-copy-id is not available)

# Copy the public key content
cat ~/.ssh/id_ed25519.pub

# On the remote server, append to authorized_keys
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3... [email protected]" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

The authorized_keys File

~/.ssh/authorized_keys on a server lists every public key authorized to log in as that user. Each line is one public key:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... laptop-2026
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... work-desktop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQ... legacy-key

Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Wrong permissions are the most common reason key authentication silently falls back to password authentication.

authorized_keys options

You can prefix a key with options to restrict its use:

# Restrict to specific command only
command="/usr/bin/backup-script.sh" ssh-ed25519 AAAA... backup-key

# Restrict source IP
from="203.0.113.0/24" ssh-ed25519 AAAA... office-key

# Disable port forwarding
no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... restricted-key

ssh-agent: Avoid Typing Passphrases Repeatedly

ssh-agent holds decrypted private keys in memory for the duration of your session. You enter the passphrase once; the agent handles authentication for all subsequent connections.

Starting ssh-agent

On most modern Linux desktops, the agent starts automatically with your desktop session. On servers or in scripts:

eval "$(ssh-agent -s)"
# Output: Agent pid 12345

Adding keys to the agent

# Add default key (~/.ssh/id_ed25519)
ssh-add

# Add a specific key
ssh-add ~/.ssh/work_ed25519

# Add with a time limit (key removed after 4 hours)
ssh-add -t 14400 ~/.ssh/work_ed25519

Enter the passphrase when prompted. The agent stores the decrypted key.

Listing loaded keys

ssh-add -l

Output:

256 SHA256:AbCdEfGh... [email protected] (ED25519)

If you see The agent has no identities., no keys are loaded. Run ssh-add.

Removing keys from the agent

# Remove a specific key
ssh-add -d ~/.ssh/work_ed25519

# Remove all keys
ssh-add -D

Adding Keys to GitHub and GitLab

GitHub

  1. Copy your public key: bash cat ~/.ssh/id_ed25519.pub

  2. Go to GitHub → Settings → SSH and GPG keys → New SSH key.

  3. Paste the public key, give it a descriptive title, click Add SSH key.
  4. Test: bash ssh -T [email protected] # Hi username! You've successfully authenticated, but GitHub does not provide shell access.

GitLab

  1. Go to GitLab → Profile → Preferences → SSH Keys → Add new key.
  2. Paste the public key content.
  3. Set an expiry date (optional but recommended for security).
  4. Test: bash ssh -T [email protected] # Welcome to GitLab, @username!

Key Rotation

Rotate SSH keys regularly — at minimum when: - An employee with server access leaves the organization. - A device that held the private key is lost or compromised. - You suspect unauthorized access. - Your organization's security policy mandates it (annually is common).

Rotation procedure

  1. Generate a new key: bash ssh-keygen -t ed25519 -C "work laptop 2026-03" -f ~/.ssh/work_ed25519_new

  2. Add the new public key to servers: bash ssh-copy-id -i ~/.ssh/work_ed25519_new.pub user@hostname

  3. Test the new key: bash ssh -i ~/.ssh/work_ed25519_new user@hostname

  4. Remove the old key from authorized_keys on each server: bash # On the server, edit authorized_keys and delete the old key line nano ~/.ssh/authorized_keys

  5. Remove the old key from GitHub/GitLab web UI.

  6. Delete old key files locally: bash rm ~/.ssh/work_ed25519 ~/.ssh/work_ed25519.pub

Audit who has access

To find all keys in authorized_keys across a fleet:

grep -h "^ssh-" ~/.ssh/authorized_keys | awk '{print $3}' | sort

Checking Key Fingerprints

To compare a key's fingerprint (useful when GitHub or GitLab shows "SHA256:..."):

ssh-keygen -l -f ~/.ssh/id_ed25519.pub
# 256 SHA256:AbCdEfGhIjKlMn... [email protected] (ED25519)

# Legacy MD5 format
ssh-keygen -l -E md5 -f ~/.ssh/id_ed25519.pub

Related Articles

ssh