Passwordless SSH Login with SSH Keys

With key-based login, SSH checks a key pair instead of asking for your password. The private key (id_rsa) is your secret and stays with you. The public key (id_rsa.pub) goes on the server, in a file called authorized_keys. These are my original steps, followed by the method I would recommend today.

Before you start

An SSH login to the server (my original steps use root).
Keep a working session or another way into the server open until you have tested key login, so you cannot lock yourself out.

My original steps

On the remote machine (the server), create a key pair:
Terminal window
```
ssh-keygen -t rsa
```
Press Enter to accept the default location. You can set a passphrase or leave it empty.
List the .ssh folder:
Terminal window
```
ls /root/.ssh
```
```
id_rsa id_rsa.pub
```
Add the public key to authorized_keys:
Terminal window
```
cd /root/.ssh
cat id_rsa.pub >> authorized_keys
```
I have added the cd line: the cat command must be run inside /root/.ssh. >> adds to the end of the file instead of replacing it.
List the folder again:
Terminal window
```
ls
```
```
id_rsa id_rsa.pub authorized_keys
```
Now copy the id_rsa file into the $HOME/.ssh/ directory of the client machine, then connect:
Terminal window
```
ssh root@server_ip_address
```
Or copy the id_rsa file to any location on the client machine and tell SSH where it is with -i:
Terminal window
```
ssh -i location/id_rsa root@server_ip_address
```

Note (added later): this works, but it creates the private key on the server and then moves it to the client, so the secret key has been copied across and also stays on the server. The usual and safer way is the reverse: create the key on the client and send only the public key to the server. If you used the steps above, delete id_rsa from the server’s .ssh folder once the client has its copy.

The recommended way

On your client (your own computer), create a key. ed25519 is the common choice today:
Terminal window
```
ssh-keygen -t ed25519
```
This creates ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). A passphrase is recommended; ssh-agent can remember it so you are not asked each time.
Copy the public key to the server:
Terminal window
```
ssh-copy-id user@server_ip_address
```
ssh-copy-id asks for your password once, adds your public key to ~/.ssh/authorized_keys on the server and sets sensible permissions. If SSH runs on another port, add -p, for example ssh-copy-id -p 1234 user@server_ip_address.
Log in:
Terminal window
```
ssh user@server_ip_address
```
You should be logged in without a password prompt (or asked only for the key’s passphrase).

Permissions SSH needs

SSH ignores your key if the files on the server can be written by other users. On the server, for the user you log in as:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

On the client, the private key must also be readable only by you:

chmod 600 ~/.ssh/id_ed25519

The .ssh folder and authorized_keys must also be owned by that user. Your home directory must not be writable by other users either.

If it still asks for a password

Check the permissions above. This is the most common cause.
Run ssh -v user@server_ip_address to see which keys the client offers and why they are refused.
Check the server’s log (/var/log/secure on Red Hat-family systems, /var/log/auth.log on Debian and Ubuntu).

Notes for today

Security: my original steps log in as root. It is safer to log in as a normal user and use sudo. Once key login works, many admins set PermitRootLogin no (or prohibit-password) and PasswordAuthentication no in /etc/ssh/sshd_config, then restart SSH. Test a second login before closing your current session.
RSA keys still work. If you create one today, use at least 3072 bits (ssh-keygen -t rsa -b 4096), but ed25519 is shorter and is the usual choice.
Documentation: https://www.openssh.com/manual.html