# Set up SSH keys for your server

> Create an Ed25519 SSH key on Windows, macOS or Linux, copy it to your server, log in without a password and protect the private key with a passphrase and agent.

Difficulty: Beginner\
Tested on: Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 12, Debian 13, Windows 11, macOS Tahoe 26

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](/guides/connect-to-linux-server-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:

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

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

**macOS and Linux**

`ssh-copy-id` logs in once with your password and appends the key to the right file with the right permissions:

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub alex@203.0.113.10
```
**Windows**

Windows has no `ssh-copy-id`. Send the key through SSH from PowerShell instead:

```powershell
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"
```

Enter the user's password when asked.
**By hand**

On the server, logged in as the user who should accept the key:

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

Paste the single line from your `id_ed25519.pub` file, save, then set the permissions:

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

```bash
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 alex@203.0.113.10` 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

**Windows**

The `ssh-agent` service is disabled by default. In PowerShell **as an administrator**:

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

Then, as your normal user:

```powershell
ssh-add $env:USERPROFILE\.ssh\id_ed25519
```
**macOS**

Add the key to the agent and store the passphrase in your keychain:

```bash
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
```
**Linux**

Most desktop sessions start an agent for you:

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

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

```bash
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](/guides/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](/guides/ssh-hardening).
- Complete the first-hour checklist: [secure a new Linux server](/guides/secure-a-new-linux-server).

## Frequently asked questions

### Which key type should I create?

Ed25519. It is short, fast and supported by every current OpenSSH release. Use RSA with at least 3072 bits only for old systems that do not accept Ed25519.

### Do I need a passphrase?

We recommend one. Without it, anyone who copies the private key file can log in as you. An SSH agent remembers the passphrase for your session, so you type it once rather than on every connection.

### Can I use the same key for several servers?

Yes. The public key can go on as many servers as you like. Many people use one key per computer, so a lost laptop means removing one key everywhere instead of replacing all of them.

### I lost my private key. How do I get back in?

Log in another way, for example with a password if it is still allowed or through the web console if your service page shows one, then add a new public key and delete the old line from authorized_keys. If you have no way in, open a support ticket.

### Should I turn off password logins afterwards?

Yes, once you have confirmed that key logins work in a second session. Our SSH hardening guide shows the exact settings.

---

Source: <https://hyperdc.com/guides/getting-started/ssh-keys>\
Updated: 2026-10-09
