6.2Configuring and Managing the OpenSSH Server

Remote administration hinges on sshd, the OpenSSH server daemon. Left at defaults and exposed externally, it becomes a brute-force target, so L2 tests whether you can precisely apply the standard hardening moves—disabling root login, standardizing on key auth, and restricting which users may connect—down to the exact directive spelling.

6.2.1Key sshd_config directives

• The config file is /etc/ssh/sshd_config. After editing, check syntax (sshd -t) before systemctl reload sshd—restarting with a broken config risks locking yourself out.
• PermitRootLogin controls direct root login: no disables it entirely, prohibit-password disables password auth for root while still allowing key-based root login. The standard hardening choice is no.
• PubkeyAuthentication toggles public key authentication (often yes by default). PasswordAuthentication toggles password authentication; to enforce key-only auth, set PasswordAuthentication no.
• AllowUsers lists space-separated users allowed to connect (e.g., AllowUsers alice bob)—a whitelist: anyone not listed is denied.

6.2.2Host keys and key-based authentication

• Host keys prove the server's identity. Private keys /etc/ssh/ssh_host_*_key pair with public keys ssh_host_*_key.pub, one pair per algorithm (rsa/ecdsa/ed25519, etc.), normally auto-generated at package install time.
• On first connection, the client records the host key's fingerprint in ~/.ssh/known_hosts and verifies on later connections that the key has not changed, detecting man-in-the-middle attacks.
• Public key authentication flow: the client signs with its private key, and the server verifies against the matching public key registered in ~/.ssh/authorized_keys. Only the client's public key lives on the server—the private key is never distributed.

Walk through a typical hardening scenario: a bastion host exposed to the internet should disable direct root login, restrict connections to just alice and bob, and require key-only authentication. In /etc/ssh/sshd_config you would set: PermitRootLogin no (root cannot log in directly; use sudo to elevate), AllowUsers alice bob (no one else may connect), PasswordAuthentication no (reject password auth), and PubkeyAuthentication yes (allow key auth, usually already the default). The key caution is order of application and verification: immediately running systemctl restart sshd after a change risks locking everyone out if there is a key misconfiguration, so best practice is to check syntax with sshd -t, apply while keeping a separate session open, and confirm a fresh connection still works. There is also an intermediate setting, PermitRootLogin prohibit-password, which rejects password-based root login but still allows key-based root connections—useful when emergency root access should be limited to key auth. If a host key changes (e.g., server rebuild), the client's stored known_hosts entry mismatches and triggers a warning—the same warning appears for a legitimate rebuild and for a man-in-the-middle attack, so the operator must confirm the change is legitimate before updating known_hosts.

6.2.3Section summary

• Configure via /etc/ssh/sshd_config. Harden with PermitRootLogin no, PasswordAuthentication no + PubkeyAuthentication yes, and AllowUsers
• Host keys (ssh_host_*_key private / .pub public) prove server identity. Check syntax with sshd -t before applying changes