SSH Key Authentication Setup - Passwordless and Secure Login
What This Article Covers
- How to generate an SSH key pair and connect to a server
- How to deploy your public key correctly with
ssh-copy-id - How to manage multiple servers with
~/.ssh/config
Quick Summary (3 Steps)
- Run
ssh-keygen -t ed25519to generate a key pair - Run
ssh-copy-id user@serverto deploy the public key - Run
ssh user@server— no password needed
Prerequisites
- Ubuntu / Debian / RHEL-based Linux on both client and server
- OpenSSH installed on both machines
- Initial access to the server via password authentication
Why Use Key Authentication?
Key authentication is more secure than passwords and eliminates manual input for automation. The three main reasons to switch:
- Security: Your private key never leaves your local machine. No password is sent over the network.
- Brute-force resistance: A mathematically sound key length makes dictionary attacks infeasible.
- Automation: rsync, Ansible, and CI/CD pipelines can connect non-interactively.
1. Generate a Key Pair
Which algorithm should you use?
ED25519 is the current recommendation. It is shorter, safer, and faster than RSA-4096.
ssh-keygen -t ed25519 -C "your_email@example.com"
Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_ed25519 Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The -C flag adds a comment (useful for identification). It is optional.
Why set a passphrase?
A passphrase encrypts the private key file itself. Even if your machine is stolen, the key cannot be used immediately. Use ssh-agent to avoid re-entering the passphrase on every connection (see below).
Verify the generated files:
ls -la ~/.ssh/
total 16 drwx------ 2 user user 4096 May 31 10:00 . drwxr-xr-x 8 user user 4096 May 31 10:00 .. -rw------- 1 user user 419 May 31 10:00 id_ed25519 -rw-r--r-- 1 user user 107 May 31 10:00 id_ed25519.pub
id_ed25519(private key): permissions600. Never share this file.id_ed25519.pub(public key): appended to~/.ssh/authorized_keyson the server.
2. Deploy the Public Key to the Server
Use ssh-copy-id (recommended)
Run this once while password authentication is still active on the server.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_ed25519.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s) /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed user@server's password: Number of key(s) added: 1
ssh-copy-id appends the public key to ~/.ssh/authorized_keys on the server and sets correct permissions automatically.
Manual deployment when ssh-copy-id is unavailable
cat ~/.ssh/id_ed25519.pub | ssh user@server \ "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
3. Set Correct Permissions
SSH rejects key authentication when directory or file permissions are too permissive. This is intentional security behavior.
| Path | Required Permission | Reason |
|---|---|---|
~/.ssh/ |
700 |
Owner read/write/execute only |
~/.ssh/authorized_keys |
600 |
Owner read/write only |
~/.ssh/id_ed25519 |
600 |
Private key must be strictly protected |
~/.ssh/id_ed25519.pub |
644 |
Public key is safe for others to read |
Fix commands:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_ed25519
Permissions like 777 or 755 cause SSH to silently ignore the key and return Permission denied (publickey). Always check permissions first when troubleshooting.
4. Test the Connection
ssh -v user@server
The -v flag (verbose) prints the authentication process in detail.
... debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:xxxxx debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:xxxxx Authenticated to server ([x.x.x.x]:22) using "publickey".
Authenticated to server ... using "publickey" confirms key authentication is working.
5. Manage Connections with ~/.ssh/config
The ~/.ssh/config file lets you save connection settings under a short alias.
vim ~/.ssh/config
Example configuration:
Host myserver
HostName 192.168.1.100
User ubuntu
IdentityFile ~/.ssh/id_ed25519
Port 22
Host staging
HostName staging.example.com
User deploy
IdentityFile ~/.ssh/id_ed25519After saving, connect with just ssh myserver.
chmod 600 ~/.ssh/config
If ~/.ssh/config permissions are more permissive than 644, SSH may ignore the file entirely. Keep it at 600.
6. Manage Passphrases with ssh-agent
ssh-agent holds your decrypted key in memory so you only type the passphrase once per session.
# Start the agent eval "$(ssh-agent -s)" # Add your key (enter passphrase once) ssh-add ~/.ssh/id_ed25519
Identity added: /home/user/.ssh/id_ed25519 (your_email@example.com)
List registered keys:
ssh-add -l
On macOS, the system Keychain integrates with ssh-agent. Add UseKeychain yes and AddKeysToAgent yes to ~/.ssh/config to persist keys across reboots.
Summary
| Command | Purpose |
|---|---|
ssh-keygen -t ed25519 |
Generate key pair (ED25519) |
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server |
Deploy public key to server |
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys |
Fix directory and file permissions |
ssh -v user@server |
Test connection with verbose output |
eval "$(ssh-agent -s)" && ssh-add |
Cache passphrase for the session |