Configuring SSH Key-Based Authentication In Linux

SSH keys provide a safer way to access Linux servers than reusable passwords. A private key remains on the administrator’s workstation, while the server stores only the matching public key. This approach works well across RHEL, CentOS Stream, Fedora, and other Linux distributions used in Australian offices and data centres.

For administrators in Sydney, Melbourne, Brisbane, or regional locations, key authentication is especially useful when managing cloud instances over variable home or office connections. It also supports stronger access controls for systems hosted in Australian cloud regions, where organisations may need to align security practices with the Privacy Act and the Australian Cyber Security Centre’s Essential Eight guidance.

Authentication method	Main benefit	Main risk	Suitable use
Password	Simple initial setup	Brute-force and password reuse attacks	Temporary or low-risk access
SSH public key	Strong authentication without sending a password	Lost private key or poor permissions	Routine administration
Hardware-backed key	Private key is harder to extract	Extra device and recovery planning	Privileged production access
Certificate-based SSH	Centralised, short-lived credentials	More complex infrastructure	Larger organisations

Choose Keys And Access Controls

Generate an Ed25519 key on the client machine unless compatibility requirements call for RSA. Ed25519 offers strong security with a compact key and fast operations. On a Linux workstation, run:

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

Accept the default path or specify a separate filename for each environment. Protect the private key with a passphrase. The public key ends in .pub and can be copied to the server; the private key must never be emailed, committed to Git, or placed in a shared directory.

An SSH agent avoids repeatedly entering the passphrase during a work session:

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

On a shared Melbourne or Sydney operations team, each administrator should use an individual key rather than sharing one account credential. This preserves audit trails and makes revocation straightforward when staff change roles.

Prepare The Linux Server

sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

The wheel group grants administrative access on RHEL-compatible systems when configured in /etc/sudoers. Prefer a named account with sudo over direct root login, particularly for internet-facing servers.

Copy the public key with:

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

If ssh-copy-id is unavailable, create the directory manually on the server:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy id_ed25519.pub /home/deploy/.ssh/authorized_keys

The ownership and permissions matter. SSH may reject a key when the home directory, .ssh directory, or authorized_keys file is writable by another user. For broader Linux administration references, the Nginx guides section is useful when securing a web server that will sit beside SSH access.

Test The New Login Safely

Keep the current session open while testing a second terminal. Connect with verbose output so authentication problems are visible:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes deploy@server.example.com

If the connection fails, inspect the client output and the server journal:

sudo journalctl -u sshd -n 50 --no-pager
sudo sshd -t

On some older distributions, the service may be named ssh rather than sshd. Confirm the effective configuration before restarting the daemon. A practical sequence is to test the key, run sudo -v, and only then close the original session.

For RHEL 9 hosts supporting a website or reverse proxy, this RHEL 9 walkthrough can be paired with SSH hardening and firewall checks. Australian cloud deployments in regions such as AWS Asia Pacific (Sydney) should still restrict administration traffic rather than exposing SSH broadly.

Harden SSH Without Lockout

Edit /etc/ssh/sshd_config with a root-capable account and set explicit controls:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
AllowUsers deploy

AllowUsers is optional but limits which accounts can connect. Disable password authentication only after confirming that key login works from a separate terminal. If automation still depends on passwords, migrate it first rather than applying the setting during a busy maintenance window.

Use a descriptive checklist for baseline hardening:

Confirm the private key has mode 600
Confirm .ssh has mode 700
Restrict SSH with firewalld or a cloud security group
Keep a tested recovery account available

Review operational safeguards as well:

Record the key owner and creation date
Store a recovery key offline and securely
Remove departed users’ authorised keys
Check logs for repeated failed attempts

After changes, validate and reload the daemon:

sudo sshd -t
sudo systemctl reload sshd

The Essential Eight encourages multi-factor authentication for important systems, so an SSH key should not be treated as the complete security strategy. Add a hardware-backed key, bastion host, VPN, or identity-aware access layer where the risk and budget justify it. The Privacy Act also makes sensible access control important when servers handle personal information.

Verify And Maintain Access

List installed keys and remove stale entries from ~/.ssh/authorized_keys. A comment such as melbourne-laptop-2026 helps identify ownership without revealing sensitive key material. Never copy private keys onto production servers just to simplify automation.

Use configuration inspection to confirm the active policy:

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|permitrootlogin|allowusers'

Keep the SSH client and server patched through the normal RHEL, CentOS Stream, or Fedora update process. Local organisations often combine a managed service provider with cloud subscriptions, so document who owns key rotation, emergency access, and log retention. The practical takeaway is simple: create a passphrase-protected key, install only its public half, test a second session, then disable password and root SSH access.