Set up SSH keys instead of passwords: proper instructions

SSH public-key authentication proves possession of a private key without sending a reusable server password. Create the key on the computer that will connect, retain the private half there, and install only the matching public half on the server. A copied, unlocked private key can still be used by an attacker, so protect it with a unique passphrase and do not place it in email, chat, source control, or an unencrypted shared folder. Keep an existing password-authenticated server session open until a separate key-only login has succeeded.

Tools and preparation

A computer with OpenSSH: it is normally present on maintained Linux and macOS systems and is available in current Windows PowerShell or Windows Terminal.

A server account that you can currently log into, plus sudo or other administration access only if password authentication will later be disabled.

The hostname, account name, and a recovery route such as provider console access or a second tested administrator key.

A secure place for the key passphrase and a record of which person and device owns each key.

Use a separate key for each person and preferably each device. It means a lost laptop can be revoked by deleting one line from the server rather than replacing every credential. Ed25519 is the normal choice for a new general-purpose OpenSSH key on maintained systems. Use another algorithm only where an older, documented server requirement demands it.

Numbered procedure

Inspect the local SSH directory first:

ls -la ~/.ssh

A file ending in .pub is public; its same-named file without that suffix is generally private. Do not overwrite an existing private key merely because it has a familiar name.

Create a distinctive new key:

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_laptop -C laptop-2026

Enter a long, unique passphrase when asked. The command makes the private file id_ed25519_laptop and the public file id_ed25519_laptop.pub. The private file never leaves the local machine.

Install the public key. If available, use:

ssh-copy-id -i ~/.ssh/id_ed25519_laptop.pub youruser@example.org

It requests the current password once and adds the public-key line to the server account’s ~/.ssh/authorized_keys. If ssh-copy-id is unavailable, display the public file locally, connect using the existing method, then append that one complete line to authorized_keys. On the server, use:

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

In another local terminal, force a key-only test:

ssh -i ~/.ssh/id_ed25519_laptop -o PreferredAuthentications=publickey -o PasswordAuthentication=no youruser@example.org

Success here proves the key works and that the command did not quietly fall back to a password.

Make the chosen key explicit in ~/.ssh/config:

Host my-server
    HostName example.org
    User youruser
    IdentityFile ~/.ssh/id_ed25519_laptop
    IdentitiesOnly yes

Set chmod 600 ~/.ssh/config, then test ssh my-server.

Only after repeat testing, consider setting PasswordAuthentication no in the server SSH daemon configuration. Validate the configuration first with sudo sshd -t, then reload the SSH service using the name required by that operating system. Leave the old session open and test a fresh key-only connection immediately.

Testing and common mistakes

Use a new terminal for each test. Add -v to SSH if troubleshooting; it shows offered authentication methods and keys without exposing the private key. If a key is refused, check server-side ownership and permissions, especially that .ssh is mode 700 and authorized_keys mode 600. Check that the public key is one uninterrupted line beginning with its key type.

Do not upload the private file. Only the .pub content belongs on the server.

Do not disable passwords before a forced-public-key login works from a different shell.

Do not accept a surprising changed server host key without verifying its fingerprint through a trusted administrator or console; it can indicate a rebuilt host, DNS mistake, or interception.

Do not use one shared key for a team. Individual accounts and keys support sensible removal and audit.

Do not assume changing the local key passphrase revokes an exposed key. Remove its public-key line from the server instead.

Credential safety

Remove a device key promptly when the device is lost, retired, or suspected compromised, then test a remaining authorised key. Keep encrypted backup material only where you control access, or use a hardware-backed security key with a documented recovery plan. SSH keys reduce password guessing but do not replace updates, least privilege, firewalling, log review, and a working console recovery method.

Server-side review

Review access as part of normal administration. Read the account’s authorized_keys file and identify each key by its comment, but do not rely on comments as proof of ownership: compare its fingerprint with the owner when needed. Generate a local public-key fingerprint with ssh-keygen -lf ~/.ssh/id_ed25519_laptop.pub. For accounts used only for a narrowly defined automated task, consider documented authorised-key restrictions such as a forced command or source-address restriction, after testing them carefully. Avoid granting routine interactive access to root; use named accounts and elevate only when needed.

Use an agent only on a device you trust and lock the device when unattended. An SSH agent can reduce passphrase prompts, but an unlocked agent is still an authentication capability. Before connecting to a new host, verify its hostname and host-key fingerprint through an independent channel. Do not defeat host-key checking merely to make an error disappear. When moving to another machine, create a new key there rather than copying a personal private key as a convenience. Preserve an inventory with key fingerprint, owner, purpose, installation date, and removal date. This makes incident response practical instead of speculative.