SSH keys: create, copy and use them

An SSH key pair replaces passwords with something that cannot be guessed and cannot be phished. The private key stays on your computer and never leaves it; the public key is copied to every server you want to log in to. The server encrypts a challenge with your public key, and only the holder of the private key can answer it.

1. Create the key pair

ssh-keygen -t ed25519 -C "dominik@laptop"

Accept the default file name (~/.ssh/id_ed25519) unless you already have one, and set a passphrase. The passphrase encrypts the private key on disk, so a stolen laptop or a leaked backup does not hand out server access. You will not type it on every login; the agent in step 4 takes care of that. The -C comment is just a label that ends up in the public key and helps you recognize it later.

Use ed25519 for everything current. Only choose -t rsa -b 4096 if you must connect to an old device that does not understand ed25519. To keep separate keys for work and personal servers, give the second one its own file name: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work.

You now have two files: id_ed25519 (private, mode 600, never share it) and id_ed25519.pub (public, one line, safe to paste anywhere).

2. Copy the public key to the server

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

You log in once with the password, and ssh-copy-id appends the public key to ~/.ssh/authorized_keys on the server with the right permissions. Without ssh-copy-id (Windows PowerShell, or a server you reach through a console), do it by hand:

# on the server, as the user you will log in as
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA...your public key... dominik@laptop' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

For GitHub, GitLab and cloud providers you paste the contents of the .pub file into their web form instead; cat ~/.ssh/id_ed25519.pub prints it.

3. Log in

ssh [email protected]
ssh -i ~/.ssh/id_ed25519_work [email protected]   # a key with a non-default name

The first connection asks you to confirm the server’s fingerprint; it is then stored in ~/.ssh/known_hosts. If it asks for your passphrase, that is the key working. If it asks for the account password instead, the key was not accepted: see the article on Permission denied (publickey).

4. Stop typing the passphrase: the agent

ssh-agent holds decrypted keys in memory for your login session, so you type the passphrase once:

ssh-add ~/.ssh/id_ed25519       # Linux; most desktops start an agent for you
ssh-add -l                      # list loaded keys

# macOS: store the passphrase in the keychain as well
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Add AddKeysToAgent yes to ~/.ssh/config (and on macOS UseKeychain yes) so keys load into the agent automatically the first time they are used. On Windows, enable the OpenSSH Authentication Agent service once in services.msc, then ssh-add works the same way.

5. Housekeeping

ssh-keygen -l -f ~/.ssh/id_ed25519.pub     # show the fingerprint
ssh-keygen -p -f ~/.ssh/id_ed25519         # change or add a passphrase
ssh-keygen -y -f ~/.ssh/id_ed25519         # regenerate the .pub line from the private key

• One key per device, not one key copied to every device. When a laptop is lost you remove exactly one line from authorized_keys.
• Never copy a private key over chat or email. If you need access from a new machine, generate a new key there and install its public key.
• Keep ~/.ssh at mode 700 and the private key at 600; the client refuses keys that other users could read.
• Once every account on a server has a working key, you can turn off password logins in sshd_config. Careful: do that from one session while you verify a key login in a second session, as described in the server hardening article.

Official documentation

• ssh-keygen(1)
• ssh-add(1)
• OpenSSH key management on Windows