How to generate an SSH key (ssh-keygen) and use it to log in

Short answer: ssh-keygen -t ed25519 -C "you@example.com" creates a key pair in ~/.ssh/ — a private key you keep and a .pub file you copy to every server. Press Enter to accept the default location, and set a passphrase when asked; everything below covers why, and what to do with the key once you have it.

Generating the key

ssh-keygen -t ed25519 -C "you@example.com"

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

-C sets a comment stored inside the public key — usually an email or a label like the machine’s name — purely so you can tell keys apart later in a server’s authorized_keys file. It has no effect on security.

Which key type: ed25519 or RSA

ssh-keygen -t rsa -b 4096 -C "you@example.com"

Why set a passphrase

A passphrase encrypts the private key file itself — without it, anyone who copies ~/.ssh/id_ed25519 off your disk (a stolen laptop, a backup that leaks, malware reading your home directory) can use it to log in to every server that trusts it, immediately and without needing to know the passphrase at all. With one set, that file is useless to them without also knowing the passphrase.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l   # confirm it's loaded

On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 stores the passphrase in the login keychain so it is loaded automatically on every new session, not just the current one.

Copying the public key to a server

ssh-copy-id user@203.0.113.10

ssh-copy-id logs in once with your current method (password or an existing key), appends your public key to ~/.ssh/authorized_keys on the server, and fixes the file’s permissions if they were wrong — the three things that have to go right for key login to work.

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

What authorized_keys expects

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx you@laptop

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

sshd refuses to trust authorized_keys if the file or the .ssh directory is writable by the group or by everyone — a wrong mode here is one of the most common reasons key login silently falls back to asking for a password.

Connecting with the key

ssh -i ~/.ssh/id_ed25519 user@203.0.113.10
# If the key is in the default location and name, -i isn't needed:
ssh user@203.0.113.10

To stop typing -i and the username every time for a server that is not the default key, put it in the SSH config file instead.

Windows with PuTTY

PuTTY does not read OpenSSH’s key format directly — generate the key in PuTTYgen instead (or load an existing id_ed25519 file into PuTTYgen with Conversions → Import key), save the .ppk file, and point PuTTY’s Connection → SSH → Auth → Credentials at it. Pageant, installed alongside PuTTY, plays the same role as ssh-agent — load the key into it once per session instead of unlocking it on every connection.

The full walkthrough for Windows, including the built-in OpenSSH client as an alternative to PuTTY, is in using SSH on Windows.

Turning off password login once the key works

Confirm the key logs you in successfully in a second, separate session before touching this — disabling password login while your only working session is the one about to be affected is how people lock themselves out:

PasswordAuthentication no

sudo systemctl restart sshd   # Debian/Ubuntu service name is "ssh" on some versions: systemctl restart ssh

This is one step of a larger hardening pass — the complete sequence, in an order that cannot lock you out, is in how to secure SSH access.

Key copied but still asked for a password, or refused outright? See Permission denied (publickey) for the checklist, almost always a permissions or path mismatch.

Frequently asked