Key authentication

Generate a keypair with ssh-keygen -t ed25519. Ed25519 is the current best practice: small keys (256-bit), fast, and no weak parameter choices unlike RSA.

ssh-keygen -t ed25519 -C "deploy key for server.example"

Output:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/id_ed25519
Your public key has been saved in /home/alice/.ssh/id_ed25519.pub

This creates two files:

• ~/.ssh/id_ed25519 — the private key. Treat this like a password. 600 permissions, never shared, never uploaded anywhere.
• ~/.ssh/id_ed25519.pub — the public key. Safe to copy everywhere. This is what you put on servers.

The -C comment is embedded in the public key and helps you identify the key later. The passphrase encrypts the private key on disk; without it, a stolen key file is immediately usable.

The private key never leaves the client — this is the security guarantee. During authentication:

1. The server sends a random challenge (a nonce).
2. Your SSH client signs the challenge with your private key.
3. The signature is sent to the server.
4. The server verifies the signature using the public key stored in ~/.ssh/authorized_keys.

The server never sees the private key. A network attacker who intercepts the session only sees the signature — useless without the private key that produced it. This is fundamentally different from passwords, where the actual secret must be transmitted.

~/.ssh/authorized_keys on the server authorises specific public keys. Each line is one public key. When you connect, SSH matches your public key against the list. Format:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFakePublicKeyDataHereForIllustration deploy@workstation.example

The file permissions must be correct: ~/.ssh/ directory must be 700, and authorized_keys must be 600. SSHd rejects auth from authorized_keys if the permissions are too open — this prevents other users on the server from injecting their own keys.

ssh-copy-id is the safe, automated way to add your public key:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server.example

It appends your public key to ~/.ssh/authorized_keys on the remote host (creating the file and directory if needed, with correct permissions). After this runs, you can SSH with your key instead of a password.

To add a key manually (when ssh-copy-id is unavailable):

cat ~/.ssh/id_ed25519.pub | ssh deploy@server.example \
  'mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

ssh-agent caches the decrypted private key in memory so you enter the passphrase once. Without the agent, every SSH connection prompts for the passphrase. With it:

eval "$(ssh-agent -s)"   # start agent, export SSH_AUTH_SOCK
ssh-add ~/.ssh/id_ed25519  # add key; prompts for passphrase once
ssh deploy@server.example  # no passphrase prompt — agent signs the challenge

The agent runs as a background process. The SSH_AUTH_SOCK environment variable points to a Unix domain socket; the SSH client uses this socket to ask the agent to sign challenges on its behalf. The private key never leaves the agent process — the client only receives the signature.

To see what keys are loaded:

ssh-add -l

To remove all keys from the agent (for example before stepping away):

ssh-add -D

Agent forwarding (-A) lets remote hosts use your local agent — but carries risk. If you SSH to a bastion and then SSH from the bastion to an internal server, normally the bastion would need its own key for the internal server. With agent forwarding, the internal server’s SSH challenge is forwarded back through the bastion to your local agent:

ssh -A deploy@bastion.example   # enable forwarding for this session

The risk: the root user on bastion.example can access your agent socket and impersonate you to any other server your agent can reach. Agent forwarding should only be enabled on bastion hosts you fully trust and control. For most multi-hop setups, ProxyJump in ~/.ssh/config (covered in the previous lesson) is safer because the hop is handled locally, with no agent exposure on the intermediate host.