SSH Hardening: The Complete Guide to Securing Remote Access in 2026

Why SSH is worth getting right

SSH (Secure Shell) is how you administer Linux servers, push code, tunnel traffic, and reach appliances. It replaced Telnet precisely because Telnet sent everything — including passwords — in plaintext. But installing SSH is not the same as securing it. A default sshd configuration that accepts passwords and allows root login is one of the most common ways internet-facing servers get compromised: automated bots hammer port 22 with credential-stuffing attacks around the clock.

This guide walks through the hardening steps that matter most, from strongest to supporting. Every change goes in /etc/ssh/sshd_config unless noted, and you must reload the daemon afterward:

sudo sshd -t            # validate the config BEFORE reloading
sudo systemctl reload ssh

Always keep a second session open while you change SSH settings — if you lock yourself out, you will be glad you did.

1. Use key-based authentication (and turn off passwords)

Password authentication is the single biggest weakness. Replace it with public-key authentication: you keep a private key, the server holds your public key, and no secret ever crosses the wire.

Generate a modern key on your client:

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Ed25519 keys are small, fast, and strong — prefer them over older RSA keys (if you must use RSA, use at least 3072 bits). Once your key works, disable passwords entirely:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

With passwords off, brute-force attacks become pointless — there is nothing to guess.

2. Disable direct root login

Never let anyone log in as root over SSH. It removes accountability (everyone shares one account) and hands attackers the highest-value target. Log in as a normal user and escalate with sudo:

PermitRootLogin no

3. Limit who can connect

Restrict SSH to only the accounts that need it with an allow-list:

AllowUsers alice bob

Combine this with network controls: expose port 22 only to a management VLAN or a VPN, and put a firewall rule in front of it. SSH should almost never be open to the entire internet.

4. Protect against brute force with rate limiting

Even with passwords disabled, noisy bots waste resources and clutter logs. Fail2ban watches your auth log and temporarily bans IPs that misbehave:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Tune down the attack surface further:

MaxAuthTries 3
LoginGraceTime 20

5. Use strong, modern cryptography

Older SSH deployments still negotiate weak ciphers and MACs. Restrict the daemon to vetted algorithms so a downgrade attack cannot force something fragile:

KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

6. The supporting controls

• Change the default port (e.g., Port 2222). This is security-through-obscurity — it will not stop a determined attacker, but it dramatically reduces automated noise in your logs.


• Disable unused features: X11Forwarding no and AllowAgentForwarding no if you do not need them.


• Set idle timeouts with ClientAliveInterval 300 and ClientAliveCountMax 2 to close abandoned sessions.


• Use an SSH certificate authority at scale instead of distributing individual keys to every server.

A sane baseline config

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers alice bob

What it means for you

SSH hardening is a perfect example of defense in depth: keys instead of passwords, no root login, network isolation, rate limiting, and modern crypto each remove a different attack path. No single control is enough, but stacked together they make remote access genuinely hard to abuse. These are exactly the hardening principles tested across our networking and security tracks — from CompTIA Network+ and Security+ to Fortinet and Cisco CCNA — where "use SSH instead of Telnet, then lock SSH down" is a recurring exam theme and a real-world daily habit.