How to Set Up SSH Keys in 2026 for Passwordless Login

Setting up SSH keys takes about five minutes and replaces your server password with a cryptographic key pair that is far harder to break: you generate the pair on your own machine, copy the public half to the server, and then turn password logins off. The short version is three commands — ssh-keygen -t ed25519, ssh-copy-id user@your-server, then a one-line change to disable password auth. This guide walks through each step for a Linux VPS, explains which key type to pick in 2026, and covers the hardening step most tutorials leave out.

If you have ever typed a password every time you SSH into a box, keys remove that friction and the security risk behind it. A key is effectively an unguessable password thousands of characters long that never travels to the server, so brute-force attacks against your login stop working.

What SSH keys are and why they beat passwords

An SSH key pair is two matching files: a private key that stays on your computer and a public key you place on any server you want to reach. When you connect, the server challenges your machine to prove it holds the private key, and that proof happens without the secret ever leaving your laptop. Because the private key is enormous compared to a human password and never travels to the server, OpenSSH supports public-key authentication as a stronger login method than a reusable password.

The practical wins are immediate. You stop sending a reusable password across the network, so credential-stuffing and brute-force bots that hammer port 22 get nothing. You can log in without typing anything, which makes scripts and deploys painless. And once keys work, you can switch password logins off entirely — the single biggest reduction in attack surface a new server gets, and the reason keys are step one in any secure-first-hour VPS setup.

Which SSH key type should you use in 2026?

Not all key algorithms are equal. ssh-keygen can produce several types, but in 2026 the choice is simple for almost everyone: use Ed25519. It is fast, produces short keys, and its security is excellent; it is also the modern default that GitHub and most platforms now recommend.

Key type	Command flag	Notes
Ed25519	-t ed25519	Recommended. Fast, tiny, modern, widely supported.
RSA 4096	-t rsa -b 4096	Use only for old systems that lack Ed25519 support.
ECDSA	-t ecdsa	Works, but no reason to pick it over Ed25519.
DSA	-t dsa	Deprecated and disabled in modern OpenSSH — never use.

The one exception is a legacy server or appliance too old to understand Ed25519, where RSA at 4096 bits is the safe fallback. For a normal Linux VPS running a current OpenSSH, Ed25519 is the right answer and the rest of this guide assumes it.

How to set up SSH keys step by step

Three steps: generate the pair, copy the public key to the server, then connect.

1. Generate the key pair on your local machine (not the server):

ssh-keygen -t ed25519 -C "you@yourmachine"

Press Enter to accept the default location (~/.ssh/id_ed25519) and set a passphrase when prompted — a passphrase encrypts the private key on disk, so a stolen laptop does not hand over your servers. This creates two files: id_ed25519 (private, keep secret) and id_ed25519.pub (public, shareable).

2. Copy the public key to the server with the helper that handles permissions for you:

ssh-copy-id user@your-server-ip

It logs in once with your password and appends your public key to ~/.ssh/authorized_keys on the server. No ssh-copy-id (common on Windows/macOS)? Do it manually — paste your .pub contents into that file, and make sure the directory is 700 and the file 600, or SSH will refuse to use it.

3. Connect. Run ssh user@your-server-ip and you are in with no password prompt (only your local passphrase, if you set one). Test this in a new terminal before moving on — you must confirm key login works before you disable passwords.

Lock it down: disable password login

This is the step that turns "keys work" into "the server is actually safer," and it is the one most guides skip. As long as password authentication stays enabled, bots can still try to guess your password, keys or not. Once you have confirmed key login works, edit the SSH daemon config on the server at /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Then reload the service — sudo systemctl restart ssh on Debian/Ubuntu (sshd on some distros). From now on the server accepts only keys, and password brute-force against it becomes impossible. The OpenSSH sshd_config manual documents both directives. Keep your existing session open while you test a fresh login, so you can undo the change if something is wrong. This pairs naturally with the wider hardening in a full self-hosting-on-a-VPS walkthrough.

Managing keys: ssh-agent and picking a specific key

Once you have a key, two small tools make daily use smoother. The ssh-agent holds your decrypted private key in memory so you type the passphrase once per session instead of every connection. Start it and add your key:

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

If you have several keys and need to force a particular one — a frequent question — point SSH at it directly with ssh -i ~/.ssh/id_ed25519 user@host, or make it permanent in ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Now ssh myserver uses the right key and user automatically. A config file is worth setting up the moment you manage more than one server; it is also the cleanest way to keep work and personal keys from colliding. Back these files up the same way you would any critical data — see our 3-2-1 backup guide for a setup that actually restores.

Windows and macOS notes

Modern Windows 10/11 and macOS ship OpenSSH built in, so ssh-keygen -t ed25519 works the same in PowerShell or Terminal. On Windows, keys live in C:\Users\you\.ssh\ and you can start the agent with Start-Service ssh-agent before running ssh-add. Since ssh-copy-id is absent on Windows, copy the public key manually with type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@host "cat >> ~/.ssh/authorized_keys". Everything else — the config file, disabling passwords server-side — is identical.

FAQ

How do I use SSH keys instead of a password? Generate a key pair with ssh-keygen -t ed25519, copy the public key to the server with ssh-copy-id user@host, then confirm you can log in without a password. To fully replace passwords, set PasswordAuthentication no in the server's /etc/ssh/sshd_config and restart SSH.

What SSH key type should I use? Ed25519. It is the modern default: fast, compact, and secure. Only fall back to RSA 4096 (ssh-keygen -t rsa -b 4096) for legacy systems that do not support Ed25519. Avoid DSA and ECDSA.

How do I set up authorized_keys? ssh-copy-id does it for you by appending your public key to ~/.ssh/authorized_keys on the server. To do it by hand, paste the contents of your .pub file into that file, one key per line, and set permissions to 700 on the ~/.ssh directory and 600 on the file.

How do I force SSH to use a specific key? Use ssh -i ~/.ssh/keyname user@host for a one-off, or add an IdentityFile line under a Host entry in ~/.ssh/config to make it permanent for that server.

Are SSH keys safer than a VPN? They solve different problems. SSH keys authenticate your login to a server that is reachable on the network; a VPN or tunnel controls who can reach it at all. For hardening a public VPS, use key-only SSH; for keeping a service private, add a tunnel on top.

Sources

• OpenSSH — ssh(1) manual: authoritative description of public-key authentication and how the key exchange works.
• OpenSSH — sshd_config(5) manual: official reference for PasswordAuthentication and PubkeyAuthentication.
• OpenSSH — ssh-keygen(1) manual: official key-generation options and supported algorithms.
• GitHub Docs — Generating a new SSH key and adding it to the ssh-agent: current guidance recommending Ed25519 and using ssh-agent.