SSH & Key Authentication

Secure Shell (SSH)

Almost every server you'll ever manage has no monitor or keyboard attached - you reach it entirely over the network, and SSH (Secure Shell) is the encrypted protocol that makes this both possible and safe, replacing older unencrypted tools like telnet that sent everything, including passwords, in plain text.

Key-based authentication is the modern, preferred alternative to typing a password every time. It relies on a mathematically linked pair of keys: a private key (~/.ssh/id_ed25519) that never leaves your machine and must be kept secret, and a matching public key (~/.ssh/id_ed25519.pub) that's safe to share and gets copied onto the server, into ~/.ssh/authorized_keys. When you connect, the server challenges your client to prove it holds the private key matching one of the public keys it trusts - without the private key ever being transmitted.

Analogy: Think of the public key as a padlock you hand out freely, and the private key as the one physical key that opens it. Anyone can have a copy of the padlock (the public key) and use it to lock something meant for you - but only you, holding the one private key, can actually open it. The server keeping your public key in authorized_keys is like it holding a copy of your padlock, ready to challenge anyone claiming to be you to prove they hold the matching key.

Server hardening in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no      # keys only
Port 2222

Apply with systemctl reload sshd - recall from the systemd module that reload re-reads config without dropping any currently connected sessions, which matters a lot here: you don't want to accidentally lock yourself out of your only remote session while editing SSH settings.

Warning: SSH refuses to use a key at all if the surrounding file permissions are too loose - and this is by far the single most common reason "key auth just doesn't work" for beginners, with no obvious error explaining why. ~/.ssh must be 700 (private to you only) and authorized_keys must be 600 - if either is group- or world-writable, sshd assumes the key material could have been tampered with by someone else and silently falls back to rejecting it. If key login mysteriously fails, checking these permissions with ls -la ~/.ssh before anything else will save you real debugging time.