Ubuntu 26.04 Tutorial / Configure OpenSSH and Test Public-Key Authentication

Configure SSH keys by checking the server listener, registering only the client’s public key, and testing a fresh connection. Restrict password authentication only after key login and administrative access work, while keeping the existing session and console available.

Inspect service, socket, and address

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

Inspect the actual listener together with ssh.socket and ssh.service. Keep the existing SSH port. With the NAT plus host-only setup in the VM creation lesson, the server is .20 and Linux client .10; run key commands on that client. One inactive unit can be normal depending on socket activation.

Ubuntu’s OpenSSH guide explains installation, configuration precedence, and validation.

On the Linux client, check command -v ssh and command -v ssh-copy-id. If needed, install openssh-client with sudo apt update && sudo apt install openssh-client. Substitute the regular username created during installation, and establish an authorized initial login or console route before registering the public key. Do not weaken production authentication just for the exercise.

Verify server identity and create a client key

At the server console, inspect its host-key fingerprint with sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, then compare the first connection through a trusted route. Run the following generation and copy commands on the Linux client, not the server.

ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"
ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

Replace labuser and the address with real values, and do not overwrite an existing key file. Set and protect a passphrase. Transfer the .pub public key only; never copy the private key to the server. The copy example assumes Linux because Windows’ default SSH tools may omit ssh-copy-id.

Test a fresh key-only connection

ssh -i "$HOME/.ssh/ubuntu-lab-ed25519" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no labuser@192.168.56.20

A private-key passphrase prompt is different from a server-account password prompt. After connection, check whoami and required sudo access. On failure, inspect account, ownership, permissions on the home directory and SSH files, and server logs; do not make them world-writable.

Validate the intended authentication policy

On a new lab server intended specifically for single-key authentication, back up SSH configuration and review a separate file such as /etc/ssh/sshd_config.d/00-lab-auth.conf. Do not apply the policy below unchanged to a server with existing MFA or organizational authentication.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

OpenSSH uses the first value read for many options; inspect effective configuration instead of trusting a filename. Match rules require evaluation with actual user and client conditions through sshd -T -C. Apply this lab policy only after the private-key login is verified.

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

Apply, reboot, and recover in order

After successful syntax validation, reload authentication settings with sudo systemctl reload ssh.service when the service is actually running. This exercise does not change ports. Port or ListenAddress changes under socket activation require separately reviewing socket generation and daemon-reload behavior.

Before closing the old session, test a new key login, sudo, and rejection of unwanted authentication. Repeat after a planned reboot. If it fails, restore only the changed configuration through the console, validate, and apply it. Investigate changed host-key warnings instead of blindly deleting trust records.