Skip to main content

Set Up SSH Key Authentication

SSH key authentication uses a key pair: a private key that stays on your machine, and a public key you install on each server you connect to. Once it's set up you log in without typing a password, and the server can drop password logins entirely.

Create a key pair​

Check whether you already have one:

ls ~/.ssh/id_ed25519.pub

If not, generate it on your local machine:

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

Accept the default path (~/.ssh/id_ed25519) and give it a passphrase. The passphrase encrypts the private key on disk, so a stolen laptop doesn't hand over your servers.

You only have to type that passphrase once per session — see Stop Entering Your SSH Key Password Over and Over.

Use ed25519 unless you're connecting to something ancient that only speaks RSA, in which case use ssh-keygen -t rsa -b 4096.

Install the public key on a server​

ssh-copy-id user@server

You'll be prompted for the account's password one last time. Then test it:

ssh user@server

If you land on a shell without a password prompt, you're done. If the account has no password (see Create a Non-Root User on Debian Linux), ssh-copy-id can't authenticate — install the key through an existing root session instead.

Use a dedicated key for one host​

A separate key per host limits the blast radius if a key leaks, and keeps CI/deploy keys apart from your personal one.

Generate it with an explicit filename:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_myserver -C "myserver"

Install it, pointing ssh-copy-id at the right public key:

ssh-copy-id -i ~/.ssh/id_ed25519_myserver.pub user@server

Then tell SSH to use it, in ~/.ssh/config:

Host myserver
    HostName 192.168.1.10
    User daniel
    IdentityFile ~/.ssh/id_ed25519_myserver
    IdentitiesOnly yes

Now ssh myserver connects with the right key, user, and address. The same alias works for scp, rsync, and git.

IdentitiesOnly yes matters: without it, SSH offers every key it knows about (including everything loaded in the agent) before the one you named, and a server with MaxAuthTries set low will disconnect you before it gets to the right key.

Key considerations​

  • Permissions: ~/.ssh must be 700, private keys and ~/.ssh/config 600. SSH ignores keys with loose permissions, usually without a clear error.
  • Never copy the private key around. Only .pub files leave your machine. To reach a server from a second machine, generate a second key pair there and add its public key too — authorized_keys holds as many keys as you like.
  • Test before locking down. Confirm key login works while another session is still open, then disable password authentication on the server.

Sources​