How to Set Up SSH Passwordless Login Across Operating Systems

An SSH passwordless login gives you faster logins, no password to guess and a cleaner path to automation such as backups and file sync.

A key pair handles authentication. The public key sits on the server, the private key stays on your machine and only a client that holds the private key can connect.

Here's the part most teams skip. A private key is a credential. It opens a server exactly the way a password does, and unlike a password it never expires and rarely shows up in an access review. Passwords get rotated, audited and reviewed because every policy names them. Keys get copied into dotfiles, shared with a contractor and forgotten on a laptop that left the company two years ago.

Going passwordless is the right move

Treat key-based login as step one, not the end state. This blog covers which key type to generate, the five steps to set up key-based login on a Linux server from Windows 11, macOS or Linux, and the point where hand-managed keys should give way to short-lived certificates.

Which SSH key type to generate

Run ssh-keygen with no options on a current OpenSSH client and you get an Ed25519 key. It's been the default since OpenSSH 9.5                 (October 2023), and it's the right choice for almost every login. Pick another type only when a system you connect to can't accept it.

Two more facts to check:

1. If you must use RSA, generate at least 3072 bits: the National Institute of Standards and Technology (NIST) rates 2048-bit RSA at 112 bits of security and lists that strength as acceptable only through 2030.

2. DSA is gone: OpenSSH 10.0 (April 2025) removed it, so replace any id_dsa key still in use.

Step 1: Generate the key pair

On Linux, in the macOS Terminal or in Windows 11 PowerShell (the OpenSSH client is built in), run:

ssh-keygen -t ed25519 -C "your-email@example.com"

The -C comment is optional. It labels the public key so you can tell keys apart in authorized_keys later. Accept the default file name when prompted (~/.ssh/id_ed25519, or C:\Users\you\.ssh\id_ed25519 on Windows) unless you already have a key by that name.

Then set a passphrase. Without one, anyone who copies the file can use it. Step 4 shows how to enter the passphrase once per session instead of on every login.

You now have two files. id_ed25519 holds the private key and never leaves your machine. id_ed25519.pub holds the public key and is safe to share.

Step 2: Copy the public key to the server

On Linux or macOS, ssh-copy-id does the whole job. It creates ~/.ssh on the server if needed, appends your key to ~/.ssh/authorized_keys and sets the right permissions. Replace user and host with your server account and address:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

Windows ships the OpenSSH client without ssh-copy-id. This PowerShell command covers the same steps:

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

Both methods append rather than overwrite, so existing keys in authorized_keys keep working. You'll enter the account password one last time.

Step 3: Test the login and check the key

Open a new terminal and connect:

ssh user@host

A prompt for your key passphrase, not the account password, means key-based login works. If the server still asks for a password, run ssh -v user@host to see which keys the client offered and whether the server accepted one. The usual cause is permissions: ~/.ssh must be 700 and authorized_keys 600, both owned by the account.

Two ssh-keygen commands tell you what you're working with. The first prints the bit length, fingerprint and type of any public key, which is how you confirm a key's algorithm and size before you trust it:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

The second confirms that a private key matches the public key you deployed. No output means they match:

ssh-keygen -y -f ~/.ssh/id_ed25519 | diff - ~/.ssh/id_ed25519.pub

Step 4: Load the key into an agent

An SSH agent holds your unlocked private key in memory, so you enter the passphrase once per session.

On Linux and macOS, ssh-agent usually starts with your login session. Add the key with:

ssh-add ~/.ssh/id_ed25519

On macOS, ssh-add --apple-use-keychain ~/.ssh/id_ed25519 also stores the passphrase in Keychain.

On Windows 11, the OpenSSH Authentication Agent service is disabled by default.³ Run these first two lines once in an elevated PowerShell window. The third adds the new key and doesn't need elevation:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Windows 10 left support on October 14, 2025, so these steps assume Windows 11 or Windows Server.

Step 5: Back up the private key

A public key can be regenerated from the private key, never the reverse. Back up the private key file to an encrypted location, such as a password manager vault and keep the passphrase separate from the backup. Lose the private key and you'll create a new pair and update every server that holds the old public key.

Optional: Turn off password logins on the server

Once key login works for every account that needs access, you can refuse passwords. Keep your working session open while you make the change, then test from a second window before you close it.

Edit /etc/ssh/sshd_config and set:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication replaced ChallengeResponseAuthentication in OpenSSH 8.7; the old name still works as an alias. Leave UsePAM at yes, since Linux distributions rely on it for account and session handling. On Ubuntu and Debian, check /etc/ssh/sshd_config.d/ too: a drop-in file there overrides the main file, and cloud images often set PasswordAuthentication in one.

Restart the service to apply the change: sudo systemctl restart ssh on Ubuntu and Debian, sudo systemctl restart sshd on RHEL-based systems.

Where static SSH keys stop scaling

Key-based login beats passwords, and it leaves you with keys to manage. On five servers, that's a chore. On 500, ask yourself when anyone last reviewed authorized_keys.

• The private key lives on a laptop. A passphrase slows down anyone who copies it; it doesn't make the copy worthless.

• Every new server needs every user's public key, and every departure needs those keys removed from every server. Steps get missed.

• Keys rarely rotate. A key added in 2021 is still trusted today unless someone removed it.

• Nothing in authorized_keys tells an auditor who holds the matching private key.

• Permission errors and version mismatches, such as a server that still expects an RSA key, turn into support tickets.

Delinea's guide to SSH key management best practices walks through how to discover, vault and rotate the keys you already have.

Go passwordless without managing keys by hand

Privileged Access Management (PAM) handles the key lifecycle for you and gives your admins a faster login in return.

Secret Server discovers SSH keys across your servers, vaults them, rotates them on a schedule or at check-in, and opens the SSH session for the user without revealing the private key. Role-based access, multi-factor authentication (MFA) and approval workflows decide who gets a session. Session recording shows what they did with it.

Delinea Server PAM goes a step further and removes the standing key altogether. When an admin selects a server and chooses Use My Account, Server PAM mints an SSH certificate from its built-in certificate authority (CA), valid for that user, that target and a limited time. There's no public key to distribute, no long-lived key left on disk, and the certificate expires on its own. You can't leak a key you never held.

For your admins, that means one click replaces ssh-keygen, ssh-copy-id and the agent setup above. For the person who signs off on your next audit, it means every SSH session ties back to a named identity with a recording behind it.

Schedule a demo and watch Server PAM issue an SSH certificate for a live login.