SSH Hardening

SSH is the front door to every server you run, and the stock sshd_config that ships on Debian and Ubuntu is tuned for getting in, not for keeping attackers out. It accepts passwords, often permits root, listens on every interface, and offers a wide menu of key-exchange and cipher algorithms for backward compatibility. Anything reachable on port 22 from the public internet starts collecting credential-stuffing attempts within minutes — the only open question is whether one of them eventually guesses a password.

Hardening SSH is about removing the cheap attacks: turn off password authentication so brute force has nothing to chew on, deny root a direct login so a stolen key still needs a second escalation, and restrict who may even attempt a session. Done correctly it converts the most exposed service on the box from a guessing game into a problem that requires stealing a private key — a far harder bar. Done carelessly, the same edits lock you out of a remote machine that has no console.

Key-Based Authentication

A password is something an attacker can guess at thousands of attempts per minute against an exposed port. A key pair is not: the private key never crosses the wire, and a modern key holds far more entropy than any password a human will type. The single highest-value change you can make is to stop accepting passwords entirely, so that no amount of guessing against port 22 can ever succeed. Public keys go in the user's ~/.ssh/authorized_keys; the server verifies a signature instead of comparing a secret.

Generate ed25519 keys, not RSA. Ed25519 is a fixed 256-bit elliptic-curve key — small, fast to verify, and free of the "is 2048 bits still enough?" question that dogs RSA. Use RSA only when you must talk to something ancient that predates ed25519 support, and then never below 3072 bits. The relevant sshd_config directives:

# /etc/ssh/sshd_config.d/10-auth.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

Turning off PasswordAuthentication alone is not always enough: PAM-driven keyboard-interactive auth is a separate path, which is why KbdInteractiveAuthentication no (formerly ChallengeResponseAuthentication) sits beside it. Generate the client key with ssh-keygen -t ed25519 -C "you@host", push it with ssh-copy-id, and confirm a key login works before you disable passwords. On Red Hat and its derivatives the directives are identical; only the SELinux context around authorized_keys (the ssh_home_t label) and the firewall front end differ.

Privilege and Access Controls

Root is the account every attacker wants and the only one whose name they already know. A direct root login over SSH collapses two barriers into one: compromise the key or password and you are immediately the superuser, with nothing recorded about which human did it. Set PermitRootLogin no and require admins to log in as themselves, then escalate with sudo — which leaves an audit trail tied to a real user. If automation genuinely needs root over SSH, use prohibit-password (key-only root) rather than yes, and never a root password.

Default sshd lets every account with a shell attempt a login. Narrow that to an explicit allowlist with AllowUsers or AllowGroups, so a forgotten service account or a newly created user cannot become an SSH entry point by accident. An allowlist fails closed: anyone not named is refused before authentication even begins.

# /etc/ssh/sshd_config.d/20-access.conf
PermitRootLogin no
AllowGroups ssh-users
MaxAuthTries 3
LoginGraceTime 20

# tighter rules for one group, applied after the global block
Match Group sftp-only
    ForceCommand internal-sftp
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no

A Match block applies a subset of directives to a specific user, group, or source address, and is the right tool for "SFTP users get a chroot jail, admins do not." Order matters: directives inside a Match override the global ones for matching connections, and a Match block runs until the next Match or the end of the file. Pair it with MaxAuthTries 3 to cut off a connection after three failed attempts and LoginGraceTime 20 so half-open auth sessions cannot pile up.

Network-Level Hardening

Moving SSH off port 22 to a high port stops the noise of untargeted scanners hitting the default, which makes logs quieter — but it is obfuscation, not security. A scanner that fingerprints all 65,535 ports finds it in seconds, and a non-standard port complicates your own tooling, firewall rules, and team's muscle memory. Treat a custom port as log hygiene at best, never as a control you rely on. The real network controls are a firewall that limits who can reach the port and a tool that bans hosts that misbehave.

Restrict the source with the host firewall. On Ubuntu, ufw wraps nftables; the rules below allow SSH only from an admin subnet and rate-limit anything else. Better still, do not expose SSH to the public internet at all — put it behind a VPN or a bastion host so the port is unreachable from the open internet.

# allow SSH only from the office/VPN range
ufw allow from 10.8.0.0/24 to any port 22 proto tcp
# rate-limit anything else that reaches it (6 hits in 30s = deny)
ufw limit 22/tcp

For hosts that must stay internet-facing, fail2ban watches the auth log and inserts a firewall ban after a threshold of failed logins — its sshd jail defaults to 5 failures earning a 10-minute block, which you can raise toward a permanent one. With password auth already disabled this matters less, but it still kills the connection churn from bots and slows anyone probing key auth. On Red Hat the firewall front end is firewalld rather than ufw; fail2ban itself is identical across distributions.

Config Hygiene and Key Management

Editing the giant default /etc/ssh/sshd_config in place makes upgrades painful: package updates may ship a new default file, and your changes get buried among commented examples. Current Debian and Ubuntu ship a sshd_config.d/ directory that the main file pulls in with Include /etc/ssh/sshd_config.d/*.conf. Drop your changes into small, named files there — one concern per file — and leave the stock config untouched. Validate every change with sshd -t before reloading, because a syntax error that crashes sshd on restart can lock you out of a remote box.

Audit the live configuration with ssh-audit, an external tool that connects and reports weak key-exchange algorithms, ciphers, and MACs the server still offers — the legacy diffie-hellman-group14-sha1 exchange and CBC-mode ciphers being the usual offenders. It prints concrete directives to paste in. Host keys deserve attention too: the server's host keys are what clients pin in known_hosts, so rotating them forces every client to re-verify, and a host key that leaked — snapshot a VM image with its keys baked in, clone it, and now a dozen servers share one identity — must be regenerated per machine by deleting /etc/ssh/ssh_host_* and then running ssh-keygen -A, which recreates only the key types that are now missing.