SSH Key-Based Authentication
When you log into a remote server with SSH (Secure Shell, the encrypted protocol for running a terminal on another machine), you usually type a password. SSH key-based authentication replaces that password with a pair of cryptographic files: one you keep secret and one you put on the server. It is faster to use day to day, far harder to break than a password, and it is the standard way professionals log into Linux servers. This page shows you how to create a key pair, copy it to an Ubuntu server, and understand exactly what each piece does.
What a key pair actually is
SSH key authentication uses two matching files generated together, called a key pair:
- The private key stays on your own computer (your laptop). It is the secret. Anyone who has it can log in as you, so you never copy it anywhere or share it.
- The public key is the matching half. It is safe to share. You copy it onto every server you want to log into.
The math behind this is public-key cryptography (asymmetric cryptography): data scrambled with one key can only be verified with the other. When you connect, the server uses your public key to send a challenge that only your private key can answer. Your private key never leaves your machine and is never sent over the network. That is the core reason keys are safer than passwords.
Security tip: Your private key is the single most sensitive file on your laptop. Never email it, never commit it to Git, never paste it into a chat. If it leaks, anyone can log into your servers as you. Always protect it with a passphrase (covered below).
Why keys beat passwords
| Aspect | Password login | SSH key login |
|---|---|---|
| Strength | A human-typed password, often short and reused | A 256-bit cryptographic key, effectively unguessable |
| Brute-force risk | High — bots constantly try common passwords | Practically zero — there is nothing to guess |
| Sent over network | A hashed exchange, but tied to a weak secret | Private key never leaves your machine |
| Daily convenience | Type a password every time | Log in instantly, no typing |
| Automation | Awkward and insecure to script | Built for scripts, CI/CD, and tools |
When to use this: always, for any server you manage. Once keys work, you should disable password login entirely (see Hardening SSH). The only time to keep passwords is during initial setup before your key is in place, or on a throwaway box you will delete in minutes.
Step 1 — Generate a key pair with ssh-keygen
Run this on your local machine (your laptop), not the server. We use the ed25519 algorithm — a modern, fast, and very secure choice that you should prefer over the older RSA in 2026.
ssh-keygen -t ed25519 -C "[email protected]"The -t ed25519 flag picks the algorithm. The -C flag adds a comment (usually your email) so you can recognize the key later. You will be prompted for a file location and a passphrase — press Enter to accept the default location, and do set a passphrase.
Output:
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alex/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alex/.ssh/id_ed25519
Your public key has been saved in /home/alex/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:9mK2v...c8Qx [email protected]This creates two files in ~/.ssh/:
id_ed25519— your private key. Guard it.id_ed25519.pub— your public key. Safe to share.
The passphrase encrypts the private key file on disk. If your laptop is stolen, the thief still cannot use the key without the passphrase. To avoid retyping it constantly, your system’s ssh-agent (a small program that holds unlocked keys in memory) caches it after the first use per session.
Step 2 — Copy the public key to the server
The easiest way is ssh-copy-id. It logs in once with your password and appends your public key to the right file on the server automatically.
ssh-copy-id [email protected]Output:
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)...
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.Now log in again — you should get straight in with no password prompt (only your local key passphrase, if cached, the first time):
ssh [email protected]If ssh-copy-id is not available
On a minimal machine you can do the same thing by hand. This reads your public key and appends it to the server’s authorized list in one command:
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
"mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Step 3 — Understand ~/.ssh/authorized_keys
On the server, each user has a file at ~/.ssh/authorized_keys. It is a plain text file where each line is one public key allowed to log in as that user. When you connect, the SSH server checks whether your private key matches any public key listed here.
cat ~/.ssh/authorized_keysOutput:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILq3...8fZk [email protected]To grant a teammate access, you simply add their public key as a new line. To revoke access, delete that line. No password resets needed.
File permissions matter
SSH is strict about permissions for security. If they are too open, SSH silently refuses to use the keys. The correct settings on the server are:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys700 means only the owner can read, write, and enter the directory. 600 means only the owner can read and write the file. If logins fail mysteriously after setup, wrong permissions are the most common cause — check /var/log/auth.log on the server for clues.
Best practices
- Always use ed25519 keys and always set a passphrase on the private key.
- Keep one key pair per device (laptop, work machine) rather than copying one private key around — if a device is lost you revoke just that key.
- Never store a private key in a shared folder, Git repo, or backup that others can read.
- After keys work, disable password authentication on the server (
PasswordAuthentication no) — see Hardening SSH. - Use
ssh-copy-idinstead of editingauthorized_keysby hand to avoid permission and formatting mistakes. - Back up your private key securely (e.g. an encrypted password manager) so you do not lock yourself out.
- Periodically review each server’s
authorized_keysand remove keys for people or machines that no longer need access.