How to Set Up SSH Login Without a Password on Linux

Introduction

Secure Shell (SSH) is widely used to administer Linux servers, cloud virtual machines, network appliances, and virtualization infrastructure. By default, an SSH server may authenticate a user with an account password, depending on its configuration.

SSH public-key authentication provides another method. You create a cryptographic key pair on your client computer, place the public key on the remote server, and keep the private key secure on the client. OpenSSH uses the corresponding key to authenticate your connection.

This is commonly called passwordless SSH login. It means you do not need to enter the remote account password for each connection. If your private key has a passphrase, you may still need to unlock that key unless an SSH agent handles it for you.

Prerequisites

Before starting, make sure you have:

• A client computer with an OpenSSH client installed.
• A remote Linux server running an SSH service.
• A valid user account on the remote server.
• Network connectivity to the server’s SSH port, usually TCP port 22.
• Existing authorized access to the remote account so you can initially install the public key.

The examples use a Linux client and Linux server. The same key-based authentication concept is also supported by Windows OpenSSH.

Step 1: Check the SSH client

On the client computer — the machine from which you will connect — verify that the SSH client is available.

ssh -V

If the command displays an OpenSSH version, the client is available. If it is missing, install the OpenSSH client using your distribution’s package manager.

Ubuntu or Debian

sudo apt update
sudo apt install openssh-client

Fedora

sudo dnf install openssh-clients

RHEL-compatible distributions

sudo dnf install openssh-clients

Package names can differ by distribution and release. If SSH is already installed, skip the installation commands.

Step 2: Generate an SSH key pair

Run the following command on your client computer, not on the remote server:

ssh-keygen -t ed25519 -C "adminuser@client"

The command generates a private key and a matching public key. The comment helps you identify the key later.

When prompted:

1. Press Enter to accept the default file location if you want to use the standard key.
2. Enter a strong passphrase to protect the private key at rest.
3. Confirm the passphrase.

The default files are:

To list the generated files:

ls -l ~/.ssh/id_ed25519*

Step 3: Copy the public key to the remote server

If you can currently access the server using an account password, the simplest method is ssh-copy-id. Run this command on the client:

ssh-copy-id adminuser@192.0.2.10

Replace adminuser and 192.0.2.10 with your remote username and server address. Enter the remote account password when prompted so the public key can be installed.

The utility normally appends the public key to the remote user’s ~/.ssh/authorized_keys file. It does not need to copy the private key.

To specify a particular key explicitly:

ssh-copy-id -i ~/.ssh/id_ed25519.pub adminuser@192.0.2.10

If the SSH service listens on a non-default port, use the port option:

ssh-copy-id -p 2222 -i ~/.ssh/id_ed25519.pub adminuser@192.0.2.10

Here, 2222 is an example port. Use the actual configured port on your server.

Alternative: Install the public key manually

If ssh-copy-id is unavailable, you can install the public key manually. First display the public key on the client:

cat ~/.ssh/id_ed25519.pub

Copy the entire single-line public key. Log in to the server using an authorized method and run the following commands as the target user:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Append the public key as a new line in ~/.ssh/authorized_keys. Use a text editor, such as nano ~/.ssh/authorized_keys, and paste the public key on its own line. Do not overwrite existing authorized keys.

nano ~/.ssh/authorized_keys

Save the file and exit the editor. Ensure the target user owns the .ssh directory and its files. For example, an administrator can correct ownership with:

sudo chown -R adminuser:adminuser /home/adminuser/.ssh

Change the username and home directory to match the actual account. For accounts whose home directory is elsewhere, use the correct path.

Step 4: Test SSH login without the account password

Return to the client computer and connect to the server:

ssh adminuser@192.0.2.10

If key authentication works, you should connect without entering the remote account password. You may still be prompted for the key’s passphrase if it is encrypted and not already unlocked by an SSH agent.

To verify that the connection used public-key authentication, run a verbose connection test:

ssh -v adminuser@192.0.2.10

Look for debug messages indicating that a public key was offered and accepted. The exact wording depends on the OpenSSH version.

Step 5: Configure SSH to use the correct key

If you manage several servers or use multiple keys, you can define a connection profile in the client-side SSH configuration file.

Create or edit the file:

nano ~/.ssh/config

Add an entry such as:

Host lab-server
    HostName 192.0.2.10
    User adminuser
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Restrict the file permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config

You can now connect using the alias:

ssh lab-server

The profile makes repeated connections easier and explicitly selects the key to offer for this host.

Step 6: Use ssh-agent for a protected private key

Using a passphrase is recommended for private keys stored on a client computer. The SSH agent can keep a key unlocked during your session so you do not have to enter the passphrase for every connection.

Start the agent in a supported shell session and add your key:

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

Enter the key passphrase when requested. The agent’s lifecycle and startup behavior vary between Linux desktop environments, shells, and operating systems.

Step 7: Optional — disable SSH password authentication

Once key-based login has been tested successfully, administrators may choose to disable SSH password authentication. This is a separate, optional hardening step. Installing an SSH key alone does not disable password login.

On the server, back up the SSH daemon configuration before editing it:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Open the configuration file:

sudo nano /etc/ssh/sshd_config

Ensure the following setting is effective:

PubkeyAuthentication yes
PasswordAuthentication no

Check for conflicting directives and configuration snippets before applying changes. Some distributions use files under /etc/ssh/sshd_config.d/, and included settings can affect the effective configuration.

Validate the daemon configuration before reloading the service:

sudo sshd -t

If validation succeeds, reload or restart the SSH service using the correct service name for your distribution.

Ubuntu and Debian

sudo systemctl reload ssh

RHEL, Rocky Linux, AlmaLinux, and Fedora

sudo systemctl reload sshd

If reload is unsupported or does not apply the change, use the distribution’s documented service procedure. Keep the existing session open while testing a fresh connection.

Confirm the effective settings where supported:

sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication) '

The expected effective values are:

pubkeyauthentication yes
passwordauthentication no

Other authentication paths, such as keyboard-interactive or PAM-backed authentication, may also need review if your objective is to prohibit all password-based SSH access. Do not change them without understanding your server’s authentication policy and recovery requirements.

Troubleshooting SSH key authentication

Inspect SSH service logs

On Ubuntu or Debian, inspect the SSH service journal:

sudo journalctl -u ssh --since "15 minutes ago"

On systems using the sshd service unit:

sudo journalctl -u sshd --since "15 minutes ago"

Review authentication logs for relevant errors and protect log output when sharing it, as it may contain usernames, addresses, or other operational details.

SSH key security best practices

• Protect private keys with a strong passphrase where practical.
• Never send your private key through email, chat, or file-sharing services.
• Use separate keys for different users, devices, or operational purposes when appropriate.
• Remove or revoke public keys that are no longer authorized.
• Keep OpenSSH and the operating system patched.
• Use least-privilege accounts and avoid routine direct root login.
• Restrict SSH network access with firewalls, VPNs, or trusted source addresses where appropriate.
• Maintain a tested recovery path before changing authentication settings.
• Use centralized access management and auditing for production environments.

Official documentation and further reading

• Ubuntu Server documentation: OpenSSH server — SSH keys, key generation, and public-key installation.
• Ubuntu manual page: ssh-copy-id — Options for installing public keys on remote systems.
• Microsoft Learn: Key-based authentication in OpenSSH for Windows — Key management and public-key deployment for Windows OpenSSH.
• OpenSSH manual pages — Official command and configuration references.

Conclusion

SSH key-based authentication is a practical way to simplify Linux server administration while using cryptographic credentials instead of repeatedly entering an account password. Generate an Ed25519 key pair, install only the public key on the server, and test a new connection before making any authentication policy changes.

For production servers, protect private keys, maintain a recovery path, and consider disabling password authentication only after confirming that all required users and automation workflows can authenticate successfully.

Editorial note: Commands and configuration examples should be tested against the target distribution and OpenSSH version before use in production. Example hostnames, usernames, and addresses must be replaced with environment-specific values.