SSH keys with ed25519

A key login is faster than a password and can't be guessed by bots. Setting one up takes five minutes. Most of the problems come later: wrong permissions, keys without passphrases, and old keys nobody removed.

Published 30 October 2026. Assumes OpenSSH on your Mac and an Ubuntu or Debian server; the commands are the same on any recent Linux.

• Why ed25519
• Make the key
• Copy it to the server
• Get the permissions right
• Use ssh-agent so the passphrase isn't a chore
• Remove old keys
• Next steps

Why ed25519

ed25519 keys are short, fast, and supported by every OpenSSH version you're likely to meet. Ubuntu's server docs recommend them, and current ssh-keygen makes one by default. RSA still works, but there's no reason to pick it for a new key unless something old on the other end can't handle ed25519.

Make the key

On your Mac:

ssh-keygen -t ed25519 -C "you@macbook"

Accept the default file, ~/.ssh/id_ed25519. The public half goes to ~/.ssh/id_ed25519.pub. The comment after -C is only a label, but a good one (who, which machine) makes it easy to find this key on a server later.

Set a passphrase when it asks. The private key file then sits encrypted on disk, so a copied laptop backup or a stolen disk doesn't hand someone your servers. You'll only type it once per session; see the ssh-agent section below. To add or change a passphrase on an existing key:

ssh-keygen -p -f ~/.ssh/id_ed25519

Copy it to the server

ssh-copy-id logs in once with your password and appends the key to ~/.ssh/authorized_keys on the server, creating the file and directory if needed:

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# different port
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 [email protected]

Without -i it picks keys from your agent, or the newest ~/.ssh/id*.pub, which may not be the one you meant. -n shows what it would install without changing anything.

If password logins are already off, ssh-copy-id can't log in. Add the key through a session that already works instead: paste the one line from id_ed25519.pub at the end of ~/.ssh/authorized_keys for that user.

Then test in a new terminal:

ssh -v [email protected]

Look for Offering public key: /Users/you/.ssh/id_ed25519 followed by Authenticated.

Get the permissions right

sshd refuses to use an authorized_keys file that other users could change. If the file, the ~/.ssh directory or the home directory is writable by anyone but the owner, the key is ignored and you get asked for a password (or refused). This is the StrictModes check, on by default, and you should leave it on.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Ownership matters too. If you created the file with sudo for another user, it may belong to root:

sudo chown -R deploy:deploy /home/deploy/.ssh

When a key login fails and the key looks right, the server's log usually says why: sudo journalctl -u ssh -n 50.

Use ssh-agent so the passphrase isn't a chore

ssh-agent holds your unlocked key in memory, so you type the passphrase once instead of on every connection. macOS starts an agent for you.

# add your default keys to the agent
ssh-add

# list what the agent holds
ssh-add -l

# add with a lifetime, e.g. 8 hours
ssh-add -t 8h ~/.ssh/id_ed25519

To have keys added automatically the first time you use them, put this in ~/.ssh/config on your Mac:

Host *
    AddKeysToAgent yes

Use one key per device rather than copying the same private key between machines. If a laptop is lost, you remove one line from each server and every other device keeps working. If you have several keys, tell ssh which one to use per server, so it doesn't offer them all and run into the server's limit on attempts:

Host your.server.example
    User you
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Don't forward your agent to servers you don't fully trust (ForwardAgent). Anyone with root there can use your keys while you're connected.

Remove old keys

Every line in authorized_keys is a working login. Keys from a laptop you sold, a contractor who left, or a CI system you replaced should go. First see what's there:

ssh-keygen -lf ~/.ssh/authorized_keys

Each line shows the key's fingerprint and its comment. Compare fingerprints with the keys you still use (ssh-keygen -lf ~/.ssh/id_ed25519.pub on your Mac).

cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak
nano ~/.ssh/authorized_keys

Check every user, not just your own, including /root/.ssh/authorized_keys. Lines starting with # are comments and are ignored.

Next steps

Once keys work for everyone who needs access, turn password logins off: disable SSH password authentication. Then go through the rest of hardening SSH without locking yourself out.

Sources

1. OpenBSD manual: ssh-keygen(1)
2. Ubuntu manpage: ssh-copy-id(1)
3. OpenBSD manual: sshd(8) (authorized_keys format, permissions)
4. OpenBSD manual: ssh-add(1)
5. Ubuntu Server docs: OpenSSH server (ed25519 recommendation)