SSH Key Authentication for Secure Remote Access

SSH keys provide a safer alternative to password-only logins for Linux servers. A private key remains on the administrator’s workstation, while the matching public key is installed on the remote host. The server can then verify the key without receiving or storing the private credential.

This approach suits RHEL, CentOS Stream, Fedora, and similar systems managed from offices, home networks, or Australian cloud regions. It also supports automation, reduces password-guessing exposure, and gives administrators a clearer way to revoke access when staff, contractors, or devices change.

Prepare The Client And Server

Update the client and server before changing SSH settings. On RHEL-based systems, use:

sudo dnf update
sudo dnf install openssh-clients

The server needs the SSH daemon and firewall access:

sudo dnf install openssh-server
sudo systemctl enable --now sshd
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Confirm that the server has a stable address or DNS name. An administrator working between a Melbourne office, a Sydney data centre, and a home NBN connection should use a hostname rather than relying on a changing public IP address.

Generate A Strong Key Pair

Create an Ed25519 key on the client:

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

Accept the default path, usually ~/.ssh/id_ed25519, or specify a separate filename for each environment. Protect the private key with a long passphrase. The public key ends in .pub and can be copied to servers; the private key must never be emailed, uploaded to a ticket, or stored in a shared repository.

Load the key into the local SSH agent so the passphrase does not need to be entered for every connection:

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

On a shared administration workstation, use individual operating-system accounts rather than passing one private key among several people. This preserves accountability in access logs.

Install The Public Key

The simplest transfer method is:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@server.example.com

If ssh-copy-id is unavailable, append the public key through an existing password-authenticated session:

cat ~/.ssh/id_ed25519.pub | ssh admin@server.example.com \
  'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

Check ownership and permissions on the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R admin:admin ~/.ssh

For restricted test environments, a CentOS chroot guide can help separate experiments from production filesystems. Keep the SSH key deployment outside the chroot unless the test specifically requires its own authentication configuration.

Harden The SSH Daemon

After confirming key-based login in a second terminal, edit /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Apply the configuration safely:

sudo sshd -t
sudo systemctl reload sshd

Do not disable password authentication until an independent key session works. Keep the current session open as a recovery path. On systems using SELinux, retain the correct context if files are copied manually:

restorecon -Rv ~/.ssh

A non-standard SSH port can reduce casual scanning noise, but it is not a substitute for keys, firewall rules, or intrusion monitoring. Use AllowUsers or AllowGroups to limit who may log in, and consider MaxAuthTries to reduce repeated attempts.

Compare Common Authentication Methods

Method	Security profile	Administration	Suitable use
Password only	Vulnerable to guessing and reuse	Simple initially	Temporary bootstrap access
Ed25519 key	Strong when the private key is protected	Requires key lifecycle management	Normal administrator access
RSA key	Widely compatible, use a modern size	More legacy support	Older systems
Hardware-backed key	Strong resistance to key theft	Needs compatible hardware and setup	High-value infrastructure
SSH certificate	Centralised trust and expiry	Requires certificate authority	Larger organisations

Australian organisations often align access controls with the ACSC Essential Eight, especially for privileged accounts. The framework is guidance rather than a universal SSH rule, but MFA, restricted administration paths, and prompt removal of departing staff are sensible controls. If logs contain personal information, consider obligations under the Privacy Act 1988 when deciding retention, access, and storage practices.

Test Access And Troubleshoot

Test the connection explicitly:

ssh -i ~/.ssh/id_ed25519 admin@server.example.com

Use verbose output when authentication fails:

ssh -vvv -i ~/.ssh/id_ed25519 admin@server.example.com

On the server, inspect recent events with:

sudo journalctl -u sshd -n 50
sudo ausearch -m USER_LOGIN -ts recent

Common causes include a wrong username, an incorrect public key, permissions that are too open, or an SSH agent offering a different key first. sshd -t identifies syntax errors before a reload. A firewall, security group, or corporate VPN may also block port 22, particularly when connecting from a managed office network in Brisbane or Perth.

Manage Keys Over Time

Record which person, device, and purpose each key represents. A useful comment might include an asset number and expiry month, without exposing sensitive information. Remove old entries from authorized_keys when a laptop is replaced, a contractor’s engagement ends, or a user leaves the organisation.

For larger fleets, use configuration management or an identity platform rather than manually editing dozens of servers. Keep encrypted backups of approved public-key records, rotate private keys periodically, and protect privileged keys with a hardware security token where practical. Monitor failed logins and alert on unexpected locations, while remembering that an IP address alone does not prove a person’s physical location.

SSH key access is strongest when the private key is passphrase-protected, the server accepts only approved public keys, root login is disabled, and every account has an accountable owner. The key point to remember is simple: protect the private key as carefully as the server itself.