How to Set Up SSH Keys on a VPS

Quick answer: generate a key pair on your own computer, push the public half to the server, then log in without a password:

ssh-keygen -t ed25519
ssh-copy-id user@your-server-ip
ssh user@your-server-ip

That is the whole flow. The rest of this guide explains each step, the manual fallback when ssh-copy-id is not available, and how to turn off password logins safely once keys work.

Why keys instead of passwords

An SSH key pair is two matched files: a private key that never leaves your computer and a public key you place on the server. The server challenges your client to prove it holds the private key. Nothing secret crosses the network, there is nothing to guess, and automated password-stuffing bots hitting port 22 become background noise instead of a threat.

Step 1: generate a key pair

On your local machine (Linux, macOS, or Windows with OpenSSH installed), run:

ssh-keygen -t ed25519 -C "workstation-2026"

• -t ed25519 selects a modern, fast, compact key type. If you must support very old servers, use -t rsa -b 4096 instead.
• -C adds a comment so you can recognize the key later. Use anything you like.

Accept the default location (~/.ssh/id_ed25519) unless you manage multiple keys. When asked for a passphrase, set one: it encrypts the private key on disk, so a stolen laptop does not mean a stolen server. Your OS keychain or ssh-agent can cache it so you rarely retype it.

You now have two files: id_ed25519 (private, never share it, never upload it) and id_ed25519.pub (public, safe to hand out).

Step 2: copy the public key to the server

The easy way, from your local machine:

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

You authenticate with your password one last time and the tool appends your public key to ~/.ssh/authorized_keys on the server with correct permissions.

Manual method

If ssh-copy-id is unavailable (some minimal images and Windows setups), do it by hand. Print your public key locally:

cat ~/.ssh/id_ed25519.pub

Then on the server, paste it into authorized_keys:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your key... workstation-2026" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The permissions matter: OpenSSH refuses keys if ~/.ssh or authorized_keys are group or world writable.

Step 3: test the key login

ssh user@your-server-ip

If your key has a passphrase you will be asked for that (locally) instead of the account password. To see what the client is doing when something fails, add -v for verbose output.

Step 4: disable password logins, safely

Do this only after a key login works, and keep your current session open while you change it. An open session survives a botched config and lets you fix it.

Edit the SSH daemon config on the server:

sudo nano /etc/ssh/sshd_config

Set these lines (add them if missing):

PasswordAuthentication no
PubkeyAuthentication yes

Some systems also ship override files in /etc/ssh/sshd_config.d/; check that none of them re-enables PasswordAuthentication. Validate the config before applying it:

sudo sshd -t

No output means the syntax is fine. Then reload:

sudo systemctl restart ssh

(The service is named sshd on some distributions.) Now open a second terminal and confirm you can still log in with your key before closing the original session.

Make daily use painless: config aliases and the agent

Typing ssh -i ~/.ssh/id_ed25519 [email protected] -p 2222 gets old fast. Put the details in ~/.ssh/config on your local machine:

Host web1
    HostName 203.0.113.7
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Now ssh web1 does the whole thing, and every tool that rides on SSH (scp, rsync, git) understands the alias too. One block per server; the file can hold as many as you manage.

If you set a passphrase, let the agent cache it once per session instead of retyping it:

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

macOS and most Linux desktops start an agent automatically and can remember the passphrase in the system keychain, so in practice you type it about once per reboot.

When you manage several servers, resist the urge to copy the same private key everywhere you work from. Generate one key per device instead, and add each device's public key to the servers it should reach. Revoking a lost laptop then means deleting one line from authorized_keys, not rotating everything.

Troubleshooting

• Still asked for a password: permissions are the usual culprit. On the server: chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys, and make sure your home directory itself is not group writable.
• Wrong user: keys are per account. A key installed for root does not log in deploy. Check which user you are connecting as.
• Multiple keys: tell the client which one to use: ssh -i ~/.ssh/id_ed25519 user@host, or set it permanently in ~/.ssh/config.
• Locked out: use your provider's web console or recovery access to re-enable PasswordAuthentication, restart SSH, and retrace the steps.

Every Linux server you deploy from our store supports key authentication out of the box, and most images let you supply the public key at order time so the first login is already password-free.