Passwordless auth through SSH

SSH key-based authentication is one of the most important security improvements you can make to any server. Instead of relying on a password — which can be brute-forced, leaked, or forgotten — your server trusts a cryptographic key pair that only you possess. This guide walks through generating an SSH key pair, deploying the public key to your remote host, and then hardening the server by disabling password logins entirely.

Check for existing keys

Before generating a new key pair, check whether one already exists on the machine you will be connecting from:

ls ~/.ssh

If you see files such as id_ed25519, id_rsa, or id_ecdsa (with matching .pub counterparts), you already have a key pair and can skip the generation step. If you want to start fresh, back up any existing keys before deleting them — never delete a key that is still authorised on a remote server.

Generating a new key pair

Modern best practice is to use the Ed25519 algorithm, which offers stronger security and shorter keys than RSA:

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

If you need compatibility with older servers that do not support Ed25519, use a 4096-bit RSA key instead:

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

When prompted for a save location, press Enter to accept the default (~/.ssh/id_ed25519). You will then be asked to set a passphrase. A passphrase encrypts the private key on disk — if someone steals your key file, they still cannot use it without the passphrase. It is strongly recommended to set one.

Once complete, verify the two files were created:

ls ~/.ssh
# id_ed25519  id_ed25519.pub  known_hosts

id_ed25519 is your private key. Treat it like a password — never share it, never copy it to a remote server, and keep it backed up securely. id_ed25519.pub is your public key. This is what you place on servers you want to access.

Copy your public key to the remote server

The easiest way to deploy your public key is with ssh-copy-id. This command appends your public key to the remote server’s ~/.ssh/authorized_keys file and sets the correct permissions automatically:

ssh-copy-id USERNAME@IP-ADDRESS

Note: This is the last time you will need to use your password for this server. Test the key-based connection before proceeding.

If ssh-copy-id is not available (e.g. on some macOS setups without Homebrew), you can do the same thing manually:

cat ~/.ssh/id_ed25519.pub | ssh USERNAME@IP-ADDRESS \
  'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Test that everything works:

ssh USERNAME@IP-ADDRESS

You should be logged in without being asked for a password. If you see “Agent admitted failure to sign using the key”, add your key to the agent:

ssh-add ~/.ssh/id_ed25519

Store your passphrase in the macOS Keychain

On macOS, you can store your key passphrase in the system Keychain so it is loaded automatically at login. Add the following to ~/.ssh/config:

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

Then load the key once:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Note: The older ssh-add -K flag was deprecated in macOS 12 Monterey. Use --apple-use-keychain on modern macOS.

Disable password authentication on the server

Once key-based login is confirmed working, disable password authentication to eliminate that attack surface entirely:

sudo nano /etc/ssh/sshd_config

Find (or add) these lines:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Reload the SSH daemon:

sudo systemctl reload ssh

Important: Do not close your current SSH session until you have opened a second terminal and confirmed you can still connect. With password authentication disabled, brute-force and credential stuffing attacks become completely ineffective against your server.