---
title: "How to Set Up SSH Key-Based Authentication on a Linux Server"
description: "How to log in to a Linux server with SSH keys instead of a password: generate a key pair, install the public key on the server, and disable password login safely."
url: "https://docs.noiz.ie/linux/how-to-set-up-ssh-key-based-authentication-on-a-linux-server/"
section: "How to Linux"
categories:
  - "Server Administration > Linux Basics > SSH"
tags:
  - "ssh"
  - "linux"
  - "security"
  - "vps"
  - "keys"
last_reviewed: "1 August 2026, against the current OpenSSH releases on Ubuntu and Debian"
---

# 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](/linux/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:

```bash
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:

```bash
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:

```bash
cat ~/.ssh/id_ed25519.pub
```

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

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

## 3. Test the key login

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

```bash
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.

## 4. Disable password login (optional, recommended)

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:

```bash
sudo nano /etc/ssh/sshd_config
```

Set these, then reload SSH:

```
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
```

```bash
sudo systemctl reload ssh
```

On Ubuntu, `/etc/ssh/sshd_config` starts with `Include /etc/ssh/sshd_config.d/*.conf`, and for most settings OpenSSH uses the first value it reads. A file in that directory therefore overrides the main file: on cloud images, cloud-init can write `50-cloud-init.conf` there with `PasswordAuthentication yes`, which silently keeps password login switched on. Check the directory, change or remove any conflicting line, reload SSH, then confirm the settings actually in force:

```bash
sudo grep -ri 'passwordauthentication' /etc/ssh/sshd_config.d/
sudo sshd -T | grep -iE 'passwordauthentication|pubkeyauthentication|permitrootlogin'
```

`sshd -T` should report `passwordauthentication no`. See the [Ubuntu OpenSSH server guide](https://ubuntu.com/server/docs/how-to/security/openssh-server/) and the [sshd_config manual](https://man.openbsd.org/sshd_config) for the detail.

`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](/linux/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](/solusvm/how-to-access-your-vps-via-the-vnc-console-in-solusvm/) or [Virtualizor](/virtualizor/how-to-access-your-vps-via-the-vnc-console-in-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.

---
Source: https://docs.noiz.ie/linux/how-to-set-up-ssh-key-based-authentication-on-a-linux-server/