How to Set Up Passwordless SSH Login

Secure Shell (SSH) is a cryptographic network protocol used for a secure connection between a client and a server. It supports various authentication mechanisms, the two most popular being password-based authentication and public-key-based authentication. If you are new to SSH, see our SSH command guide and SSH config file guide .

In this guide, we will show you how to set up SSH key-based authentication and connect to your Linux server without entering a password.

Quick Reference #

For a printable quick reference, see the SSH cheatsheet .

Check for Existing SSH Keys #

Before generating a new SSH key pair, check if you already have one on your client machine so you do not overwrite existing keys.

Run the following ls command to see if existing SSH keys are present:

ls -al ~/.ssh/id_*.pub

If there are existing keys, you can either use those and skip the next step or back up the old keys and generate a new one.

If you see No such file or directory or no matches found, it means that you do not have an SSH key and you can proceed with the next step.

Generate a New SSH Key Pair #

The recommended key type is Ed25519, which offers better security and performance than RSA with shorter keys:

ssh-keygen -t ed25519 -C "your_email@domain.com"

If you need to work with older systems that do not support Ed25519, you can generate a 4096-bit RSA key instead:

ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"

Our guide on generating SSH keys with ssh-keygen goes deeper into key types, custom filenames, and managing more than one key pair.

Press Enter to accept the default file location and file name:

Enter file in which to save the key (/home/yourusername/.ssh/id_ed25519):

Next, the ssh-keygen tool will ask you to type a secure passphrase. Whether you want to use a passphrase is up to you. If you choose to use a passphrase, you will get an extra layer of security. In most cases, developers and system administrators use SSH without a passphrase because it is useful for fully automated processes. If you do not want to use a passphrase, just press Enter.

Enter passphrase (empty for no passphrase):

A sample interaction looks like this:

To verify that the SSH keys were generated, list your new private and public keys with:

ls ~/.ssh/id_*

/home/yourusername/.ssh/id_ed25519 /home/yourusername/.ssh/id_ed25519.pub

Copy the Public Key to the Server #

Now that you have generated an SSH key pair, you need to copy the public key to the server you want to manage.

The easiest way to copy your public key to your server is to use the ssh-copy-id command. On your local machine, type:

ssh-copy-id remote_username@server_ip_address

You will be prompted to enter the remote_username password:

remote_username@server_ip_address's password:

Once the user is authenticated, the public key will be appended to the remote user’s authorized_keys file and the connection will be closed.

If for some reason the ssh-copy-id utility is not available on your local computer, you can use the following command to copy the public key:

cat ~/.ssh/id_ed25519.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Copy a Non-Default Key #

If you generated a key with a custom filename, specify it with -i:

ssh-copy-id -i ~/.ssh/id_ed25519_work.pub remote_username@server_ip_address

Log In Using SSH Keys #

After completing the steps above, you should be able to log in to the remote server without being prompted for a password.

To test it, try to log in to your server via SSH:

ssh remote_username@server_ip_address

If everything went well, you will be logged in immediately.

Using the SSH Agent #

If you set a passphrase on your key, you will be asked to enter it every time you connect. To avoid this, you can use ssh-agent to cache your passphrase for the duration of your session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The agent will remember your passphrase until you log out or the agent is stopped.

Loading Keys into the Agent Automatically #

To load the key into the agent automatically on first use, add this block to ~/.ssh/config:

Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

AddKeysToAgent yes pushes the key into a running ssh-agent the first time it is used, so the passphrase is requested only once per session. IdentityFile selects the key explicitly, and IdentitiesOnly yes prevents the client from offering every key from the agent and triggering Too many authentication failures on strict servers.

Generating SSH Keys on Windows #

Windows 10 and later include a built-in OpenSSH client. You can use the same commands shown above directly in PowerShell or Command Prompt.

To generate a key on Windows, open PowerShell and run:

ssh-keygen -t ed25519 -C "your_email@domain.com"

The keys will be stored in C:\Users\your_username\.ssh\. To copy the public key to the server, you can use the following PowerShell command:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Disabling SSH Password Authentication #

To add an extra layer of security to your server, you can disable password authentication for SSH.

Before disabling SSH password authentication, make sure you can log in to your server without a password and the user you are logging in with has sudo privileges.

The following tutorials describe how to configure sudo access:

• How to create sudo user on Ubuntu
• How to create sudo user on CentOS
• How to create sudo user on Debian

Log into your remote server with SSH keys, either as a user with sudo privileges or root:

ssh sudo_user@server_ip_address

On Ubuntu 22.04, Debian 12, and other recent releases, /etc/ssh/sshd_config begins with an Include /etc/ssh/sshd_config.d/*.conf line. OpenSSH uses the first value it obtains for each keyword, and the included files are read in lexical order, so a directive set in a drop-in file wins over the same directive further down in the main file. Cloud images are where this bites most often: cloud-init writes /etc/ssh/sshd_config.d/50-cloud-init.conf with PasswordAuthentication yes, and editing sshd_config alone changes nothing.

Check whether your server uses drop-in files:

ls /etc/ssh/sshd_config.d/

If the directory is empty or missing, edit /etc/ssh/sshd_config directly and set the following directives:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

If the directory already contains files, add your own drop-in with a name that sorts before them. A file named 99-hardening.conf is read after 50-cloud-init.conf and loses to it, so use a low number instead:

sudo nano /etc/ssh/sshd_config.d/01-hardening.conf

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Save the file and test the configuration syntax before restarting anything:

sudo sshd -t

If the command prints no output, the syntax is valid. Confirm that the values you set are the ones OpenSSH will actually use:

sudo sshd -T | grep -iE "passwordauthentication|pubkeyauthentication"

pubkeyauthentication yes
passwordauthentication no

This dumps the effective configuration after all includes are resolved, so it is the only reliable way to confirm that a drop-in file is not overriding you. Once the output is correct, restart the SSH service.

On Ubuntu or Debian servers:

sudo systemctl restart ssh

On Fedora, RHEL, and derivatives:

sudo systemctl restart sshd

Recent Ubuntu releases start SSH through socket activation, which spawns a fresh sshd for each connection. The authentication changes above apply to the next login either way. Before closing the session, open a second terminal and confirm that key login still works.

Troubleshooting #

Permission denied (publickey)
The server did not accept the offered key. Check three things: the public key is appended to the remote ~/.ssh/authorized_keys, the remote ~/.ssh is 700 and authorized_keys is 600, and the username in ssh user@host matches the account that owns authorized_keys. Run ssh -v user@host to see which keys are being offered.

Authentication refused: bad ownership or modes for file
The remote authorized_keys file or ~/.ssh directory has loose permissions. Fix with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys on the server.

PasswordAuthentication no has no effect
A file under /etc/ssh/sshd_config.d/ sets the directive before the main file does, and OpenSSH keeps the first value it obtains. Run sudo sshd -T | grep -i passwordauthentication to see the effective value, then edit the drop-in that sets it or add one with a lower-numbered filename.

Too many authentication failures
The client is offering every key in ~/.ssh/ and the server cuts the session after the limit. Use ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes user@host for a one-shot fix, or set IdentitiesOnly yes for the host in ~/.ssh/config.

Could not open a connection to your authentication agent
ssh-agent is not running in the current shell. Start it with eval "$(ssh-agent -s)" and re-run ssh-add.

FAQ #

What is the difference between Ed25519 and RSA keys?
Ed25519 keys are shorter, faster, and considered more secure than RSA. They are supported on OpenSSH 6.5+ (released 2014). Use RSA only if you need compatibility with very old systems.

Can I use the same key for multiple servers?
Yes. You can copy the same public key to as many servers as you want using ssh-copy-id.

What permissions should the SSH files have?
The ~/.ssh directory should be 700, the private key should be 600, and the authorized_keys file should be 600. Incorrect permissions will cause SSH to reject the key.

How do I use different keys for different servers?
You can configure per-host keys in your SSH config file (~/.ssh/config) using the IdentityFile directive.

Do I need to edit /etc/ssh/sshd_config to log in with a key?
No. Key-based login works out of the box on most distributions. You only edit the server configuration when you want to turn password authentication off afterwards.

Conclusion #

SSH key-based authentication lets you log in without typing an account password while keeping access tied to your private key. After you confirm key login works from a second terminal, disabling password authentication reduces the attack surface for public SSH servers.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page