SSH & Remote Administration — Linux Administration Level 9

SSH key-based authentication

ssh-keygen, ssh-copy-id, and why key auth is both more secure and more convenient than passwords. · 10 min

SSH key authentication uses a key pair: a private key that never leaves your machine and must be protected like a password, and a public key that's safe to share and gets placed on servers you want to access. When you connect, the server challenges your client to prove it holds the private key matching a public key it already trusts — this happens through public-key cryptography, not by ever transmitting the private key itself, which is exactly why it's more secure than password authentication: there's no password to intercept, phish, or brute-force over the network.

`ssh-keygen` generates a new key pair, by default `~/.ssh/id_ed25519` (private) and `~/.ssh/id_ed25519.pub` (public) — ed25519 is the modern, recommended algorithm; older RSA keys still work but need a larger bit size (4096) to be considered comparably strong today. Setting a passphrase on the private key during generation adds a second layer: even if the private key file is stolen, it's useless without that passphrase — skipping the passphrase for convenience is a real, common tradeoff worth thinking about rather than a purely technical decision.

`ssh-copy-id user@host` is the standard way to install your public key onto a server's `~/.ssh/authorized_keys` file for that user, after which key-based login works automatically. Once key-based login is confirmed working, disabling password authentication entirely in `sshd_config` (covered in the next lesson) removes password brute-forcing as an attack vector against SSH completely, not just partially.

Command	Purpose	Example
ssh-keygen -t ed25519	Generate a new SSH key pair using the modern ed25519 algorithm	—
ssh-copy-id user@host	Copy your public key to a server's authorized_keys for passwordless login	—
ssh user@host	Connect to a remote host	—
scp file user@host:/path	Copy a file to/from a remote host over SSH	—
sftp user@host	Open an interactive file-transfer session over SSH	—

Full key setup, start to finish

# On your local machine
$ ssh-keygen -t ed25519 -C "your-email@example.com"
# Accept the default path, set a passphrase when prompted

$ ssh-copy-id deploy@203.0.113.10
# Enter the password ONE more time — for this copy operation only

$ ssh deploy@203.0.113.10
# Logs in with no password prompt — key auth confirmed working

Common Mistakes

⚠ Copying the private key (id_ed25519, no .pub extension) to a server instead of the public key — the private key must never leave your own machine
⚠ Setting overly permissive permissions on ~/.ssh or the private key file — SSH will refuse to use a private key that's readable by anyone but its owner
⚠ Deleting or losing a private key with no backup and no other access method configured — plan key rotation and recovery before you need it, not after

Takeaway: The private key never leaves your machine and proves your identity cryptographically — that's what makes key auth immune to password interception, phishing, and brute-forcing in a way password auth fundamentally isn't.

Hardening sshd_config

The specific settings that matter most for a server exposed to the internet. · 10 min

`/etc/ssh/sshd_config` controls the SSH server's (sshd) behavior, and a handful of settings make an outsized difference to real-world security. `PermitRootLogin no` disables direct SSH login as root — administrators should log in as a named, individual user and use `sudo` for privileged actions, both for the audit trail and because it removes root as a directly guessable, universally-present login target. `PasswordAuthentication no` disables password-based login entirely once key-based access is confirmed working, eliminating the most common attack surface against SSH: automated password brute-forcing.

`Port 22` is SSH's default — changing it to a non-standard port doesn't meaningfully improve security against a targeted attacker (a port scan finds it in seconds), but it does measurably reduce log noise from the constant background scanning that hits port 22 on every internet-facing IP, which can make genuine security-relevant log entries easier to spot. This is a minor operational convenience, not a real security control, and shouldn't be relied on as one.

After changing `sshd_config`, always run `sudo systemctl reload sshd` (not `restart`, which briefly drops all existing connections) to apply changes — and critically, test the new configuration in a second, still-open SSH session before closing your only connection. A syntax error or an overly restrictive setting in `sshd_config` can lock you out entirely if you disconnect before confirming the new config actually works, especially on a remote server with no other access method (like a cloud console) as a fallback.

Command	Purpose	Example
sudo systemctl reload sshd	Apply sshd_config changes without dropping existing connections	—
sudo sshd -t	Test sshd_config syntax without actually applying/restarting — catches errors before they lock you out	—

A reasonably hardened sshd_config excerpt

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deploy admin

# AllowUsers restricts login to only these named accounts —
# anyone else, even with a valid key, cannot log in via SSH at all.

Common Mistakes

⚠ Setting `PasswordAuthentication no` before confirming key-based login actually works — this can lock you out with no fallback
⚠ Closing your only SSH session immediately after editing sshd_config, before testing a fresh connection in a second session
⚠ Using `systemctl restart sshd` instead of `reload` — restart briefly drops every active connection, including the one you're using to make the change

🧪

Hands-On Lab

Secure an SSH server

Ubuntu Server 24.04 LTS

Objectives

✓ Confirm key-based login works before changing any server-side settings
✓ Disable root login and password authentication
✓ Verify the new configuration without locking yourself out

⚠️ Warning: Never disable password authentication until you have personally confirmed key-based login works in a separate, still-open session.

Instructions

Generate a key pair locally and copy it to the server with `ssh-copy-id`, if you haven't already from the previous lesson.
Open a second SSH session to the server (keep your first session open as a safety net) and confirm key-based login works with no password prompt.
Edit `/etc/ssh/sshd_config` and set `PermitRootLogin no` and `PasswordAuthentication no`.
Run `sudo sshd -t` to check for syntax errors before applying anything.
Run `sudo systemctl reload sshd`.
From a THIRD, brand-new terminal, attempt to connect fresh with your key — only once this succeeds should you consider closing your original safety-net session.

Hints (1)

If the new connection fails, your still-open original session is your recovery path — fix the config and reload again before doing anything else.

Takeaway: Never close your only working SSH session while testing a config change that could lock you out — keep one session open as a safety net until a brand-new connection in a separate session confirms the new settings work.