How to Use SSH Keys Instead of Passwords

SSH keys are more secure and more convenient than passwords: they resist brute-force attacks and let you log in without typing a password every time. This guide shows you how to generate a key pair, install it on a server, and harden your SSH configuration.

How SSH Key Authentication Works

An SSH key pair has two halves. The private key stays on your computer and must never be shared. The public key is copied to any server you want to access. When you connect, the server uses the public key to issue a cryptographic challenge that only your private key can answer. Because the private key never travels across the network, this is far harder to compromise than a reusable password.

Read also: Essential Linux Commands for Beginners (With Examples)

Step 1: Generate Your Key Pair

On your local machine, create a modern Ed25519 key, which is fast and secure:

ssh-keygen -t ed25519 -C "[email protected]"

You’ll be prompted for a file location (accept the default ~/.ssh/id_ed25519) and a passphrase. Set a passphrase — it encrypts the private key on disk, so a stolen laptop doesn’t hand over instant access. If your environment requires RSA, use ssh-keygen -t rsa -b 4096 instead. This produces two files: the private key and the public key ending in .pub.

Step 2: Copy the Public Key to the Server

The easiest method is ssh-copy-id, which appends your public key to the server’s authorized list:

ssh-copy-id user@server-ip

It will ask for your password one last time, then install the key. If ssh-copy-id isn’t available, do it manually:

1. cat ~/.ssh/id_ed25519.pub — copy the printed line.
2. Log in to the server, then run mkdir -p ~/.ssh && chmod 700 ~/.ssh.
3. Append the key to ~/.ssh/authorized_keys and set chmod 600 ~/.ssh/authorized_keys.

Correct permissions matter: SSH refuses to use these files if they’re too open.

Step 3: Test and Then Disable Password Login

From your local machine, connect again:

ssh user@server-ip

If you set a passphrase, you’ll be asked for it locally, not for the server password. Once key login works reliably, harden the server by editing /etc/ssh/sshd_config as root:

• PasswordAuthentication no — turn off password logins entirely.
• PermitRootLogin prohibit-password — allow root only via keys, or set to no.
• PubkeyAuthentication yes — ensure key auth is enabled.

Apply the changes with sudo systemctl restart sshd. Keep your current session open while you test a new connection from another terminal, so you don’t lock yourself out.

Step 4: Use the SSH Agent for Convenience

So you don’t retype your passphrase all day, load the key into the agent:

• eval "$(ssh-agent -s)" — start the agent.
• ssh-add ~/.ssh/id_ed25519 — add your key; enter the passphrase once.

For frequent connections, create a ~/.ssh/config entry with a Host alias, HostName, User, and IdentityFile so you can simply type ssh myserver.

Frequently Asked Questions

Should I use Ed25519 or RSA keys?

Use Ed25519 — it’s faster, produces shorter keys, and offers strong security. Only fall back to rsa -b 4096 when connecting to older systems that don’t support Ed25519.

Do I really need a passphrase on my key?

Yes. The passphrase encrypts your private key on disk, so if someone steals the file they still can’t use it. Combine it with ssh-agent to avoid repeated typing.

Why does SSH still ask for my password after adding the key?

Usually the key wasn’t installed correctly or permissions are wrong. Verify ~/.ssh is 700 and authorized_keys is 600 on the server, and connect with ssh -v to see why the key is being rejected.

Is it safe to disable password authentication?

Yes, and it’s strongly recommended once key login works. It eliminates brute-force password attacks. Just confirm a new key-based session succeeds before closing your existing connection.