Setup SSH Key Access


January 11, 2025
Written by Sean David Reed
OS/Distro: Ubuntu 24.04.1 LTS

Client Side

Check for existing SSH keys. If they exist, try using them instead, or back them up and generate new ones. If keys are overwritten, other SSH connections could be disrupted.

$ ls -al ~/.ssh/*.pub

Generate a 4096-bit key pair. Simply hit enter for "file in which to save" and passphrase (leaving it blank).

$ cd ~/.ssh 
$ ssh-keygen -t rsa -b 4096 -C "email@domain.com"

# Windows
C:\> ssh-keygen -t rsa -b 4096 -C "email@domain.com"

Copy the public key (with the .pub extension) from the client to the server. You will be prompted to enter your password.

$ ssh-copy-id -i ~/.ssh/yourkey.pub remote_user@server_ip_address

# Windows (solution found on superuser.com):
C:\> type %USERPROFILE%\.ssh\id_rsa.pub | ssh user@host "cat >> .ssh/authorized_keys"

Verify that you can SSH into your server without a password.

$ ssh remote_user@server_ip_address

# Windows
C:\> ssh remote_user@server_ip_address

Disable Password Authentication - Server Side

Disabling Password Authentication will require any machine that wants to access the server to have the private key. This will provide better security than Username and Password access.

Open the sshd_config file.

$ sudo vim /etc/ssh/sshd_config

Modify the fields PasswordAuthentication, ChallengeResponseAuthentication, and UsePAM.

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
  • In my case, I couldn't find ChallengeResponseAuthentication even after running /ChallengeResponseAuthentication in Vim. Adjusting the other fields seemed to do the trick though. Needs further investigation.

Restart the SSH service.

sudo systemctl restart ssh

Verify that you cannot SSH into the server by trying to establish a connection from a machine without the private key. Done!

If Password Authentication Still Works [added 1/5/2026]

Something is overriding your changes in /etc/ssh/sshd_config. Inspect the config file for any lines that contradict your changes. There could be another PasswordAuthentication yes lurking in the file higher up than the line you changed. In my case, I had this file in another part of my ssh configuration.

# /etc/ssh/sshd_config.d/50-cloud-init.conf

PasswordAuthentication yes

This file was linked into sshd_config.

# /etc/ssh/sshd_config

# ...

Include /etc/ssh/ssh_config.d/50-cloud-init.conf

# ...

PasswordAuthentication no

This include statement took precedence over my change because it appeared first. I deleted the file 50-cloud-init.conf since it contained nothing but the PasswordAuthentication field. If it contained other important fields, I would have simply set PasswordAuthentication to no there as well.

Resources Used