Set up SSH keys for your server

An SSH key pair has two parts: a private key that stays on your computer and a public key that you put on the server. When you connect, your computer proves that it holds the private key, so no password crosses the network and there is nothing for attackers to guess. This guide creates a key, installs it on your server and tests it.

Before you start

• You can already log in to the server, for example as root with the password from the welcome email. See connect to your Linux server with SSH.
• You know which user you will log in as. In the examples the user is alex and the server is 203.0.113.10; replace both with yours.
• On Windows 10 and 11 the OpenSSH client is built in; macOS and Linux include it as well.

Step 1: Create a key pair

Run this on your own computer, not on the server:

ssh-keygen -t ed25519 -C "alex@laptop"

The -C value is only a comment that helps you recognise the key later. Press Enter to accept the default file, then enter a passphrase twice.

Verify: two files now exist in the .ssh folder of your home directory: id_ed25519 (private, never share it) and id_ed25519.pub (public). Show the fingerprint with:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

On Windows the folder is C:\Users\YourName\.ssh, and PowerShell understands ~ in this command as well.

Step 2: Copy the public key to the server

ssh-copy-id -i ~/.ssh/id_ed25519.pub alex@203.0.113.10

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh alex@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

chmod 600 ~/.ssh/authorized_keys

Each line in authorized_keys is one public key. Keep one key per line, and never paste a private key there.

Step 3: Test the key

Open a new terminal and connect:

ssh -i ~/.ssh/id_ed25519 alex@203.0.113.10

Verify: the client asks for the key's passphrase (not the server password) and logs you in. Run ssh -v [email protected] if you want to see it in detail: a line such as Authenticated to 203.0.113.10 ([203.0.113.10]:22) using "publickey". confirms that the key was used.

Step 4: Let an agent remember the passphrase

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent

ssh-add $env:USERPROFILE\.ssh\id_ed25519

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

ssh-add ~/.ssh/id_ed25519

Verify: ssh-add -l lists the key's fingerprint, and new connections no longer ask for the passphrase.

Step 5: Save a shortcut (optional)

Add an entry to the file ~/.ssh/config on your computer:

Host myserver
    HostName 203.0.113.10
    User alex
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Now ssh myserver is enough. IdentitiesOnly yes makes the client offer only this key, which avoids "Too many authentication failures" when you have many keys.

Using PuTTY instead

PuTTY uses its own key format (.ppk). Open PuTTYgen and either select Generate with the key type EdDSA (Ed25519), or load your existing OpenSSH key with Conversions › Import key. Set a passphrase, then Save private key. Copy the text from the box "Public key for pasting into OpenSSH authorized_keys file" into the server's authorized_keys as in Step 2. In PuTTY, choose the .ppk file under Connection › SSH › Auth › Credentials before you select Open, and save the session.

Hardware security keys

If you own a FIDO2 security key, you can create a key that only works while the device is plugged in and touched:

ssh-keygen -t ed25519-sk

The server must run OpenSSH 8.2 or newer, which every current Ubuntu and Debian release does. Keep a second key or another way in, in case the device is lost.

Troubleshooting

The server still asks for a password. The key was not accepted. Check on the server that ~/.ssh is 700, authorized_keys is 600, both belong to the user, and that the key is on one unbroken line. ssh -v shows which keys your client offered.

Permission denied (publickey). Password logins are already off and the key is not accepted. Use another way in (the web console if your service page shows one) and fix authorized_keys. See SSH connection problems.

WARNING: UNPROTECTED PRIVATE KEY FILE! Your private key file is readable by other users. On macOS and Linux run chmod 600 ~/.ssh/id_ed25519. On Windows, remove other users from the file's permissions in its Properties › Security tab.

Too many authentication failures. Your agent offered too many keys. Add IdentitiesOnly yes and an IdentityFile line for this server, as in Step 5.

Next steps

• Turn off password and root logins: SSH hardening.
• Complete the first-hour checklist: secure a new Linux server.