Skip to main content
If you manage multiple servers, logging in with passwords every time quickly becomes tedious and insecure. Passwords can be guessed, reused, or brute-forced, and they make automation brittle. This guide replaces password-based SSH logins with secure key-based authentication, explains what happens under the hood, covers the manual and recommended methods, and shows the server-side SSH configuration you should verify.

​
How key-based authentication works (short overview)

  • You generate an asymmetric key pair on your client: a private key (keep secret) and a public key (shareable).
  • You copy the public key to the remote server and append it to the user’s ~/.ssh/authorized_keys.
  • The SSH daemon on the server verifies incoming connections by checking the public key and ensuring the connecting client can prove possession of the corresponding private key.

​
Manual method (what happens under the hood)

  1. Generate a key pair:
  • -t specifies the key type (examples: ed25519, rsa).
  • This creates ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public) by default.
  1. Transfer the public key to the server (example methods):
  • Copy or append the contents of ~/.ssh/id_ed25519.pub into the remote user’s ~/.ssh/authorized_keys (ensure correct permissions).
  • Or use scp/sftp to transfer the public key then append it on the server.
  • The ssh-copy-id utility automates this and sets correct permissions — see the practical method below.
Use ssh-copy-id to safely install your public key on the remote host:
ssh-copy-id appends the public key to ~/.ssh/authorized_keys on the remote server and sets the proper permissions. It’s faster, less error-prone, and ideal for most workflows.
Prefer ed25519 keys for modern security and performance, unless you need RSA for compatibility. Protect your private key with a passphrase and use an SSH agent (e.g., ssh-agent + ssh-add) to avoid re-entering the passphrase frequently.

​
Important sshd_config options (server-side)

SSH server configuration typically lives in /etc/ssh/sshd_config (and files under /etc/ssh/sshd_config.d/). The following options control authentication behavior and are commonly adjusted when enabling key-based logins. Example relevant section from /etc/ssh/sshd_config:
To enforce only key-based authentication, set:
Then restart sshd:
Always confirm at least one account can log in with its key before disabling password authentication to avoid accidental lockout.

​
Demo: Configuring Key-based Authentication

A dark-themed presentation slide titled "Demo: Configuring Key-based Authentication" on the left. On the right is a simple blue line-art icon showing a user outline and a padlock.
This demo walks through the steps: creating users, generating keys, installing the public key on the target server, and updating sshd_config.
  1. Create the test user on both systems (control and node1)
On the control system (as root):
On node1 (as a normal user with sudo):
Now both systems have a test user with the same temporary password (used only for initial setup).
  1. Generate an SSH key pair for the test user on the control node
Switch to the test user and generate keys:
Verify the generated files:
  • id_ed25519 is the private key — keep it secret.
  • id_ed25519.pub is the public key — safe to copy to servers.
  1. Install the public key on node1 using ssh-copy-id
From the control node as test:
  1. Test SSH login using the key
From the control node as test:
Example successful shell prompt on node1:
  1. Inspect and adjust /etc/ssh/sshd_config on node1 (as root)
Open the server config:
Make sure these lines are present and correctly set (uncomment if necessary):
Save the file and restart sshd:
  1. Verify behaviour for different users
  • A user without an installed key (for example student) should be denied if PasswordAuthentication no is set:
  • A user with a key (for example test) should succeed:
This demonstrates that test can log in via key-based authentication while password logins are disabled for other accounts.

​
Summary and best practices

  • Create a key pair with ssh-keygen -t ed25519 and install the public key using ssh-copy-id.
  • Ensure PubkeyAuthentication yes is enabled on the server and only set PasswordAuthentication no after confirming key logins work.
  • Disable direct root SSH login with PermitRootLogin no.
  • Protect private keys with a passphrase and use an SSH agent to manage passphrases securely.
  • Keep at least one administrative account with working key access before disabling passwords to avoid lockouts.
Before disabling password authentication, verify that at least one user account can authenticate using key-based SSH. Otherwise you risk locking yourself out of the server.

Watch Video