SSH Passwordless Login: How to Set Up and Disable It in Linux

Direct answer: Linux passwordless SSH usually means public-key authentication. Generate an Ed25519 key pair on your client, install the public key in the server account’s ~/.ssh/authorized_keys, test a new connection, then disable password and keyboard-interactive authentication in the effective sshd configuration. Keep the private key protected with a passphrase when practical; passwordless refers to avoiding the remote account password, not removing protection from the private key.

How SSH key authentication works

The client keeps a private key. The server stores the matching public key. During login, OpenSSH proves that the client possesses the private key without sending it to the server. The account password remains available for local console or other permitted uses unless you change it separately.

Prerequisites and safety checks

A Linux client with OpenSSH client tools and a target server running OpenSSH.
An account that can log in and write to its home directory.
Console, out-of-band, or a second administrator session for recovery.
Keep your current SSH session open while changing authentication settings.

Never disable password authentication from your only remote session before a fresh key-based login succeeds.

Set up passwordless SSH step by step

1. Generate an Ed25519 key pair

ssh-keygen -t ed25519

Press Enter to accept the default path, usually ~/.ssh/id_ed25519. Set a passphrase when practical. The private file must stay on the client; share only the .pub file.

List the resulting files:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

2. Install the public key on the server

The easiest method is:

ssh-copy-id user@server

Specify a non-default key when needed:

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

If ssh-copy-id is unavailable, append the complete public-key line to the target account:

cat ~/.ssh/id_ed25519.pub | ssh user@server 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

On the server, the usual file is ~/.ssh/authorized_keys. OpenSSH can also use another path configured by AuthorizedKeysFile, or an AuthorizedKeysCommand that retrieves keys dynamically.

3. Fix ownership and permissions

For the target account, verify that the home directory, .ssh, and authorized_keys are owned by that account. A common baseline is:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$(id -gn)" ~/.ssh

Some distributions apply stricter checks to the home directory. Consult local SSH logs if the key is rejected.

4. Confirm public-key authentication is enabled

In the effective server configuration, PubkeyAuthentication yes must be enabled. Settings may be split between /etc/ssh/sshd_config and files under /etc/ssh/sshd_config.d/. Display the effective values:

sudo sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authorizedkeysfile|permitrootlogin'

5. Test a new connection

Open a second terminal and connect:

ssh user@server

If the key is not selected automatically:

ssh -i ~/.ssh/id_ed25519 user@server

A passphrase prompt for the private key is expected. A prompt for the remote account password means password authentication is still being used or the key was not accepted.

Disable password authentication safely

1. Edit the effective configuration

Set the following in the active sshd_config file or an included drop-in:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

PasswordAuthentication disables the password method. Keyboard-interactive authentication can also produce a password prompt through PAM, so review KbdInteractiveAuthentication and your PAM policy rather than changing only one setting.

2. Validate before reloading

sudo sshd -t

Fix every syntax error before applying the change. On systems where the daemon binary has a different path, use the distribution’s documented equivalent.

3. Reload and verify

sudo systemctl reload ssh
# Some distributions use this service name instead:
sudo systemctl reload sshd

Keep the original session open. From a new terminal, verify that the key works and that a password is not accepted:

ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no user@server

Choose a policy explicitly:

Setting	Effect
`PermitRootLogin prohibit-password`	Allows root public-key login while disabling root password and keyboard-interactive authentication.
`PermitRootLogin no`	Disables root SSH login entirely.

Use the setting that matches your access policy and verify the effective value with sshd -T.

Disable one key for one account

Edit that account’s ~/.ssh/authorized_keys and remove or comment the specific complete key line. Reconnect from a fresh terminal to confirm that key no longer works. This does not change the account’s local password.

nano ~/.ssh/authorized_keys
# Then test from the client:
ssh -i ~/.ssh/id_ed25519 user@server

Disable public-key authentication broadly

Set:

PubkeyAuthentication no

Validate and reload:

sudo sshd -t && sudo systemctl reload ssh

Account-specific access controls can be safer than disabling keys for every user. Review Match User blocks and included configuration files carefully.

Useful client and server options

Option	Purpose
`-i FILE`	Use a particular private key.
`-vvv`	Show detailed authentication negotiation.
`IdentitiesOnly yes`	Prevent an agent from offering unrelated keys.
`ssh-agent`	Cache a private-key passphrase for a session.
`PreferredAuthentications=publickey`	Try public-key authentication first.
`ConnectTimeout=10`	Bound connection setup time in automation.

For repeatable settings, add a host entry to ~/.ssh/config:

Host production
    HostName server.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Troubleshooting rejected keys

Symptom	Likely cause	Fix
Password prompt after key setup	Wrong key, key not installed, or public-key auth disabled.	Run `ssh -vvv`, specify `-i`, and inspect `sshd -T`.
“Permission denied (publickey)”	Bad ownership or permissions, malformed key, or wrong account.	Check the single-line key, ownership, modes, and server logs.
Key works for one user only	It was added to another account’s home directory.	Install it in the intended user’s effective `AuthorizedKeysFile`.
Changes have no effect	An included file or later `Match` block overrides the setting.	Run `sudo sshd -T` and inspect all included files.
Daemon refuses to reload	Syntax error.	Run `sudo sshd -t`, correct the reported line, then reload.
Locked out after reload	No working key or an incorrect authentication policy.	Use the open session, console, or out-of-band access to restore configuration.

On the client, collect focused diagnostics:

ssh -vvv -i ~/.ssh/id_ed25519 user@server

On the server, inspect the system authentication log using your distribution’s journal or log files. Look for messages about bad ownership, refused keys, or the selected authentication method.

FIDO2 security keys

OpenSSH supports hardware-backed FIDO/U2F algorithms such as sk-ecdsa-sha2-nistp256@openssh.com and sk-ssh-ed25519@openssh.com. Generate one with a compatible security key:

ssh-keygen -t ed25519-sk

Depending on the key and policy, the server can require a physical touch with PubkeyAuthOptions touch-required or user verification with verify-required. FIDO keys add hardware assurance; ordinary Ed25519 keys remain software-held files.

Performance, reliability, and cost considerations

Public-key authentication avoids repeated password entry and resists password guessing, but protect private keys and revoke lost keys promptly.
Use a passphrase plus ssh-agent for interactive work. In automation, restrict key scope with a dedicated account and least-privilege server permissions.
Keep a second administrator key or console recovery path before changing daemon-wide settings.
For fleets, manage authorized keys through configuration management or an authorized-keys command rather than editing files manually.
Removing a key is immediate after the daemon reads the file; existing sessions normally remain open, so terminate them separately if required.

Or skip the browser setup

If your workflow also needs screenshots of server dashboards, deployment pages, or documentation, ScreenshotNeo provides a single website screenshot API request. See the ScreenshotNeo API documentation for all options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are never billed, and response headers identify the page verdict and billing status. Its MCP server lets AI agents take screenshots, inspect pages, and capture PDFs. The Free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Does passwordless SSH remove my Linux password?

No. It changes how SSH authenticates. The account password remains unless you separately change or lock it.

Where is authorized_keys?

Usually ~/.ssh/authorized_keys for the target account, unless AuthorizedKeysFile or AuthorizedKeysCommand changes the source.

Can I disable SSH keys for just one user?

Remove that user’s key lines, or use account-specific Match User policy. Test from a new connection.

Is an Ed25519 private key passwordless?

The remote login can avoid an account password while the private key still has a passphrase.

Should I use FIDO2?

Use a FIDO2 security key when hardware-backed possession, touch, or user verification is part of your threat model and operational process.