Client area
Linux•July 24, 2026• 1 view

SSH keys: generate, install and secure access to your server

SSH keys: generate, install and secure access to your server

The password is the weak link of any server exposed on the Internet. It can be guessed, reused, intercepted, or cracked by brute force. Authentication via SSH key solves the problem at its root: instead of a secret that you type, you use a pair of cryptographic keys that are nearly impossible to guess. It's safer, and on a daily basis, it's also more convenient: no more password to enter at each login.

This guide covers the entire lifecycle of an SSH key on a Linux VPS: understanding the principle, generating a modern key pair with ssh-keygen, installing it on the server, connecting, using the SSH agent, and then completely disabling password authentication to lock down access.

How does an SSH key pair work?

Key authentication relies on two complementary files:

  • The private key remains on your computer. It must never leave your machine or be shared. It's your secret.
  • The public key is placed on the server. It can circulate freely: knowing the public key does not allow you to reconstruct the private key.

Upon connection, the server sends a challenge that only the corresponding private key can solve. If the proof is valid, access is granted without any secret traversing the network. This is what makes the method both safer than a password and resistant to eavesdropping.

Prerequisites

  • Access to your Linux VPS (Ubuntu, Debian, etc.) via SSH.
  • A terminal on your machine: Terminal on macOS/Linux, or PowerShell / Windows Terminal on Windows (OpenSSH has been integrated since Windows 10).
  • A few minutes. This is the simplest tutorial in the security journey, and the most cost-effective.

Generate an SSH key pair with ssh-keygen

The generation is done on your computer, not on the server. Open your terminal and run:

ssh-keygen -t ed25519 -C "[email protected]"

Some explanations:

  • -t ed25519 chooses the algorithm. Ed25519 is currently the recommended standard: short keys, very fast, and very secure. If you need to deal with an old system that does not support it, fall back to -t rsa -b 4096.
  • -C adds a comment (typically your email) to identify the key later.

ssh-keygen then asks two questions:

  1. The file location: confirm the default path (~/.ssh/id_ed25519) by pressing Enter.
  2. A passphrase: this is a password that encrypts your private key on disk. Choose one. Thus, even if your computer is compromised, the stolen key remains unusable. The SSH agent (see below) will prevent you from having to re-enter it at each connection.

Two files are created in ~/.ssh/:

id_ed25519        → your private key (keep it secret)
id_ed25519.pub    → your public key (to be placed on the server)

Install the public key on the server

The goal is to add your public key to the ~/.ssh/authorized_keys file of your user on the VPS. The simplest method is ssh-copy-id:

ssh-copy-id user@SERVER_IP

The command asks you for your password one last time (the server's password), then copies and configures everything automatically, with the correct permissions. You're done.

If ssh-copy-id is not available (on Windows, for example), the manual method works everywhere:

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

On macOS/Linux, the equivalent:

cat ~/.ssh/id_ed25519.pub | ssh user@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Connect with your key

Immediately test the key connection, before touching anything else:

ssh user@SERVER_IP

If you set a passphrase, it will be requested (this is the one for the key, not the server). You are connected without the server password: the key works. Do not proceed to the password deactivation step until this connection is confirmed.

Use the SSH agent to avoid retyping the passphrase

Entering the passphrase at each connection quickly becomes tedious. The SSH agent keeps your key unlocked in memory for the duration of your session. Start it and then add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

You enter the passphrase only once; subsequent connections are seamless. On macOS, you can save the key in the system keychain with ssh-add --apple-use-keychain. On Windows, enable the ssh-agent service (Get-Service ssh-agent | Set-Service -StartupType Automatic) and then ssh-add.

To list the keys currently loaded in the agent:

ssh-add -l

The SSH configuration file (practical bonus)

To avoid typing the IP and user, create a shortcut in ~/.ssh/config on your machine:

Host myvps
    HostName 203.0.113.10
    User myuser
    IdentityFile ~/.ssh/id_ed25519

A simple command ssh myvps is then enough to connect.

Disable password authentication

This is the step that truly locks down your server: once the key connection is confirmed, the password is completely prohibited. Thus, even the best brute force attack becomes useless.

Warning: do this only after verifying that the key connection works. Ideally, keep a second SSH session open during the operation as a safety net.

On the server, edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Make sure you have these directives (uncomment them and adjust the values):

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

PermitRootLogin prohibit-password allows root only via key (or disables it with no if you always go through a sudo user, which is preferable). Save, then reload the service:

sudo systemctl restart ssh

On some recent distributions, the configuration may be overridden by a file in /etc/ssh/sshd_config.d/. If PasswordAuthentication no seems ignored, check this folder. Then test a new connection: the password should no longer be accepted.

Best practices

  • One key per device. Generate a distinct pair on each machine from which you connect, rather than copying the same private key everywhere. In case of loss of a device, you simply remove its public key from the server.
  • Protect the private key with a passphrase. A private key without a passphrase offers full access to anyone who gets hold of the file.
  • Never share the private key. Only the .pub file is transmitted.
  • Backup your keys in a safe place: losing your private key means losing configured access.
  • Combine with a firewall. Restricting the SSH port and only opening what is necessary strengthens the whole setup; see the UFW step in the journey below.

Troubleshooting: "Permission denied (publickey)"

This is the most common error, and it almost always comes from file permissions. SSH refuses to use a folder or key file that is too permissive. On the server, fix:

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

Other common leads:

  • Wrong user or wrong key: check that you are connecting with the correct account and that the corresponding private key is present (ssh -i ~/.ssh/id_ed25519 user@IP).
  • Detailed diagnostic: add -v (or even -vvv) to your ssh command to see precisely which key is being offered and where it is failing.
  • Malformed authorized_keys: the public key must fit on a single line.

Frequently asked questions

Ed25519 or RSA? Ed25519 for all modern servers: shorter, faster, equally secure. RSA 4096 remains a valid fallback for older systems.

What if I lose my private key? You will no longer be able to connect with it. Reconnect by another means (another key, VPS rescue console), then remove the old public key from authorized_keys and add a new one.

Can I use the same key on multiple servers? Technically yes: just place the same public key on each. But prefer one key per workstation rather than a single key duplicated across all your machines.

Do SSH keys work on Windows? Yes, OpenSSH is integrated into Windows 10 and 11. All the commands in this guide work in PowerShell or Windows Terminal.

The server security journey

Key authentication is the first building block of a well-defended server, the one that closes the front door. To complete the process on your Linux VPS, continue with the rest of the journey:

  1. SSH Keys replace the password with key authentication (you are here).
  2. UFW close all unnecessary ports with a simple firewall (guide coming soon).
  3. Fail2ban automatically ban attackers who persist (guide coming soon).
  4. Certbot encrypt your services with a Let's Encrypt SSL certificate (guide coming soon).

Find all our tutorials in the Linux documentation. In less than ten minutes, you transform access to your server: from "vulnerable password" to "cryptographic key impossible to guess".

Back to Documentation