How to Set Up SSH Key-Based Authentication on a Linux Server

This guide shows you how to log in to a Linux server with an SSH key instead of a password. Key-based login is more convenient and far more secure than a password, and it lets you disable password login entirely so brute-force attacks have nothing to guess.

Last reviewed: 1 August 2026, against the current OpenSSH releases on Ubuntu and Debian. It complements the official OpenSSH documentation.

How it works, in one paragraph

You generate a key pair on your own computer: a private key, which stays on your machine and must never be shared, and a public key, which you place on the server. When you connect, the server uses the public key to issue a challenge only the private key can answer, so you log in without typing a password. For where these files live, see Where SSH Keys Are Stored in Linux.

1. Generate a key pair on your computer

Run this on your own machine (Linux, macOS, or Windows with OpenSSH/PowerShell), not on the server:

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

Accept the default location (~/.ssh/id_ed25519) and set a passphrase. The passphrase protects the private key if your machine is ever compromised, and an SSH agent means you only type it once per session. ed25519 is the modern choice; use -t rsa -b 4096 only if you must talk to something very old.

2. Install the public key on the server

The easiest way is ssh-copy-id, which appends your public key to the right file with the right permissions:

ssh-copy-id username@your_server_ip

If your machine does not have ssh-copy-id, do it by hand. Print your public key and copy it:

cat ~/.ssh/id_ed25519.pub

Then on the server, as the user you will log in as:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys    # paste the public key on its own line
chmod 600 ~/.ssh/authorized_keys

Open a new terminal and connect, keeping your existing session open as a safety net:

ssh username@your_server_ip

You should get in using the key (and its passphrase if you set one), not the account password. Do not proceed until this works reliably.

Once key login works, you can stop the server accepting passwords at all. This removes password brute-forcing as a threat. Edit the SSH config on the server:

sudo nano /etc/ssh/sshd_config

Set these, then reload SSH:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

sudo systemctl reload ssh

PermitRootLogin no also stops anyone logging in as root directly; use your non-root user with sudo instead (see Initial Server Setup with Ubuntu on a Noiz VPS).

If you lock yourself out

Disabling password login before your key works is the classic way to lock yourself out. Recovery does not need a reinstall: open the VNC console from your VPS panel (SolusVM or Virtualizor), which works independently of SSH, log in, and either fix the key or re-enable PasswordAuthentication yes temporarily. This is why step 3 insists on testing in a new session while the old one stays open.

Managing keys over time

One key pair per device is cleaner than copying one private key everywhere; add each device’s public key to authorized_keys (one per line).
To remove access for a device, delete its public key line from authorized_keys on the server.
If a private key may have leaked, remove its public key from every server immediately and generate a new pair.