How to set up SSH key authentication with ed25519 keys

Generate a key

ssh-keygen -t ed25519 creates a modern elliptic-curve key pair: a private key in ~/.ssh/id_ed25519 and a public key in id_ed25519.pub. Set a passphrase. It encrypts the private key on disk, so a stolen laptop backup does not hand over server access.

The -C option adds a comment, usually your name and device, which makes authorized_keys files readable later.

Snippet

ssh-keygen -t ed25519 -C "alice@laptop-2026"
ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Install it on the server

ssh-copy-id user@host appends your public key to ~/.ssh/authorized_keys on the server and sets permissions. If you do it manually, the .ssh directory must be 700 and authorized_keys 600, owned by the user, or sshd will ignore them.

ssh-agent holds the decrypted key in memory so you type the passphrase once per session. ssh-add -l lists loaded keys. Avoid agent forwarding to servers you do not fully trust, because root on that server can use your agent while you are connected.

Snippet

ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@192.168.56.101
eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
ssh -v alice@192.168.56.101 2>&1 | grep -i "authenticated using"

Lab: restrict a key

authorized_keys lines can carry options in front of the key. from="192.168.56.0/24" limits source addresses. command="/usr/local/bin/backup.sh" forces a single command. restrict disables forwarding, PTY allocation, and other features in one word. Create a second key for a backup job and install it with restrict and a forced command.

Test that the backup key runs only the script and cannot open a shell, then review every authorized_keys file on the host to see which keys exist and whose they are.

Snippet

# ~/.ssh/authorized_keys on the server
restrict,from="192.168.56.40",command="/usr/local/bin/backup.sh" ssh-ed25519 AAAAC3Nz... backup@nas

sudo find /home /root -name authorized_keys -exec sh -c 'echo "== $1"; cut -c1-80 "$1"' _ {} \;

Key lifecycle

Remove keys when people leave or devices are retired. Unlike passwords, keys do not expire unless you use SSH certificates, so stale keys accumulate silently.

For teams, a hardware security key with ssh-keygen -t ed25519-sk keeps the private key on the device and requires a touch for each use.

Diagram

Key-based login setup

Generate
Create an ed25519 key with a passphrase.
Command
```
ssh-keygen -t ed25519 -C "alice@laptop"
```
Install
ssh-copy-id the public key; check 700 and 600 modes.
Agent
Load the key into ssh-agent; avoid forwarding to untrusted hosts.
Restrict
Add from=, command=, and restrict for automation keys.

Check yourself

1. What does a key passphrase protect against?

2. sshd ignores your authorized_keys file. A likely cause?

3. Which authorized_keys option disables forwarding and PTY for a key?