How to set up SSH key authentication?

To set up SSH key authentication, generate a key pair on your local computer with ssh-keygen -t ed25519, copy the public key to your server with ssh-copy-id user@server (or paste it into ~/.ssh/authorized_keys), and then log in with ssh user@server. Once you've confirmed key login works, you can disable password authentication on the server so only key holders can connect.

SSH keys replace passwords with a pair of cryptographic keys, which makes brute-force attacks practically impossible and saves you from typing passwords all day. This guide walks through generating keys on macOS, Linux, and Windows, installing them on a server, using an SSH agent and config file, managing multiple keys, and switching off password logins safely.

How SSH Key Authentication Works

An SSH key pair has two parts:

• Private key: Stays on your computer. Never share it. Anyone with this file (and its passphrase) can log in as you.
• Public key: Can be shared freely. You place it on each server you want to access.

When you connect, the server uses your public key to issue a challenge that only the matching private key can answer. Your private key never leaves your computer, and nothing reusable is sent over the network. That's why keys are much stronger than passwords, which can be guessed, reused, or phished.

Step 1: Check for Existing Keys

On macOS, Linux, or Windows (PowerShell), look in your .ssh folder:

ls -la ~/.ssh

Files like id_ed25519 and id_ed25519.pub (or id_rsa and id_rsa.pub) mean you already have a key. You can reuse it, or create a new one for a specific purpose.

Step 2: Generate a New Key Pair

On macOS and Linux

Open a terminal and run:

ssh-keygen -t ed25519 -C "you@example.com"

• -t ed25519 selects the Ed25519 algorithm, which is modern, fast, and secure. It's the recommended default for new keys.
• -C adds a comment to help you identify the key later, such as your email or the device name.

You'll be asked where to save the key. Press Enter to accept the default (~/.ssh/id_ed25519), or give it a custom name if you're creating a key for a specific server.

Next, you'll be asked for a passphrase. Use one. A passphrase encrypts your private key on disk, so if your laptop is stolen or the file leaks, the key can't be used without it. An SSH agent means you won't have to type it constantly.

If you need to connect to an older system that doesn't support Ed25519, create an RSA key with a strong size instead:

ssh-keygen -t rsa -b 4096 -C "you@example.com"

On Windows

Windows 10 and 11 include the OpenSSH client. Open PowerShell and run the same command:

ssh-keygen -t ed25519 -C "you@example.com"

Keys are saved in C:\Users\YourName\.ssh\. Tools like PuTTY use a different key format (.ppk). If you use PuTTY, PuTTYgen can generate keys or convert an OpenSSH key.

Using a Hardware Security Key

If you have a FIDO2 security key, OpenSSH can create a key that requires the physical device to be present:

ssh-keygen -t ed25519-sk -C "you@example.com"

The private key file on disk is useless without the hardware key, which gives excellent protection against theft. The server needs a reasonably recent OpenSSH version to accept -sk keys.

Step 3: Copy the Public Key to Your Server

The Easy Way: ssh-copy-id

On macOS and Linux:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

You'll be asked for the account's password one last time. The tool then appends your public key to ~/.ssh/authorized_keys on the server and sets correct permissions.

From Windows PowerShell

Windows doesn't include ssh-copy-id, but you can pipe the key over SSH:

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

Manually

If you already have access another way, such as a provider console:

• Display your public key locally and copy the entire single line:

cat ~/.ssh/id_ed25519.pub

• On the server, logged in as the target user, run:

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

• Paste the key on its own line, save, and set permissions:

chmod 600 ~/.ssh/authorized_keys

Adding Keys When Creating a Server

Most VPS and cloud providers let you add your public key in their dashboard when you create a server. The key is then installed automatically for the initial user. This is the easiest option for new servers.

Step 4: Log In With Your Key

ssh deploy@your-server-ip

If you used a custom key name, specify it:

ssh -i ~/.ssh/myserver_ed25519 deploy@your-server-ip

If you set a passphrase, you'll be asked for it. You should not be asked for the account's password. If you are, see the troubleshooting section below.

Step 5: Use an SSH Agent

An SSH agent holds your decrypted key in memory so you only type the passphrase once per session.

macOS

Add your key and store the passphrase in the macOS Keychain:

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

Then add this to ~/.ssh/config so it loads automatically:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

Linux

Most desktop environments start an agent automatically. Otherwise:

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

Windows

Enable and start the OpenSSH Authentication Agent service from an administrator PowerShell:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Many password managers, such as 1Password and Bitwarden, can also act as an SSH agent and store your keys securely.

Step 6: Simplify Connections With an SSH Config File

Instead of typing usernames, IPs, and key paths each time, add entries to ~/.ssh/config on your local machine:

Host myserver
    HostName 203.0.113.25
    User deploy
    Port 22
    IdentityFile ~/.ssh/myserver_ed25519
    IdentitiesOnly yes

Host staging
    HostName staging.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Now you can connect with just:

ssh myserver

IdentitiesOnly yes tells SSH to offer only the specified key, which avoids "Too many authentication failures" errors when your agent holds many keys.

Step 7: Disable Password Authentication

Once key login works for every account that needs access, turn off passwords on the server. Keep your current session open and test in a new terminal after the change.

Create a drop-in config file:

sudo nano /etc/ssh/sshd_config.d/01-keys-only.conf

Add:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Validate and reload:

sudo sshd -t
sudo systemctl reload ssh

On RHEL-based systems, use sudo systemctl reload sshd. Confirm the effective setting:

sudo sshd -T | grep passwordauthentication

It should show passwordauthentication no. Now try logging in from a fresh terminal to make sure you can still get in.

Managing Keys Over Time

One Key per Device

Create a separate key on each computer you use, rather than copying one private key between machines. If a laptop is lost, you remove just that device's public key from your servers.

Restrict What a Key Can Do

In authorized_keys, you can add options before a key to limit it. For example, a key used only by a backup system, allowed only from one IP, with forwarding disabled:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3Nza...rest-of-key backup@server

You can also force a single command with command="/usr/local/bin/backup.sh", which is useful for automation keys.

Remove Old Keys

Periodically review ~/.ssh/authorized_keys on each server and delete lines for devices or people that no longer need access. Each line's comment helps you identify it, which is why meaningful -C comments are worth adding.

Change a Passphrase

You can change a key's passphrase without creating a new key:

ssh-keygen -p -f ~/.ssh/id_ed25519

Back Up Your Keys Securely

If you lose your only private key and passwords are disabled, you'll need your provider's console to regain access. Keep a secure backup in a password manager or encrypted storage, or make sure you have a second authorized key.

Troubleshooting

Still being asked for a password: Usually a permissions problem. SSH refuses keys if the directory or file is too open. On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh

The home directory itself also shouldn't be writable by others.

Permission denied (publickey): The server doesn't accept any key you offered. Check you're using the right username and key, and run SSH in verbose mode to see what's happening:

ssh -v deploy@your-server-ip

Look for lines like Offering public key and Server accepts key.

"UNPROTECTED PRIVATE KEY FILE" warning: Your private key is readable by other users. Fix it with chmod 600 ~/.ssh/id_ed25519.

Too many authentication failures: Your agent is offering too many keys. Use IdentitiesOnly yes and IdentityFile in your SSH config for that host.

Check the server logs: On Ubuntu and Debian, look at sudo journalctl -u ssh -n 50 for the reason a key was rejected.

---

FAQ: SSH Key Authentication

---

Conclusion

Setting up SSH key authentication takes only a few minutes: generate an Ed25519 key with a passphrase, copy the public key to your server, confirm you can log in, and then disable password authentication. From that point, automated password-guessing attacks against your server become pointless.

To keep things secure over time, use one key per device, load keys through an agent, keep an SSH config file for convenience, and review authorized_keys on your servers regularly. It's one of the simplest and most effective security upgrades you can make to any server you manage.