Hardening SSH on Raspberry Pi: Key-Based Auth, Fail2ban, and Reducing Your Attack Surface

A freshly-imaged Raspberry Pi with SSH enabled and left on your home network is, by default, reachable by anyone who can guess or brute-force its login — and automated scanning bots find exposed SSH ports (especially ones answering on the default port 22) within hours of a device going online, home network or not. Most Pi setup guides tell you to enable SSH and move on; they rarely cover what happens after that, which is the part that actually determines whether your Pi stays yours. This covers the specific, low-effort changes that close off the most common attack paths without making the Pi harder for you to actually use.

Step 1: Kill Password Authentication, Use Keys Instead

This is the single highest-value change you can make. Password auth is vulnerable to brute-force guessing no matter how long your password is, because the attacker gets unlimited attempts; key-based auth has no password to brute-force at all.

1. Generate a key pair on your main computer, not the Pi: ssh-keygen -t ed25519 -C "pi-access"
2. Copy the public key to the Pi: ssh-copy-id pi@<pi-ip-address> (or manually append it to ~/.ssh/authorized_keys on the Pi)
3. Test that key-based login works in a second terminal session before closing your existing one — this is the step people skip and then lock themselves out
4. Once confirmed, edit /etc/ssh/sshd_config on the Pi and set:
   • PasswordAuthentication no
   • PermitRootLogin no
   • PubkeyAuthentication yes
5. Restart the SSH service: sudo systemctl restart ssh

Keep your private key backed up somewhere other than the device you generated it on — if that laptop dies, you lose easy access to every Pi you've set up this way.

Step 2: Change the Default Port (Optional, But Cuts Noise Dramatically)

Moving SSH off port 22 doesn't stop a targeted attacker, but it eliminates nearly all the automated, opportunistic scanning traffic that constantly probes port 22 across the entire internet. Set Port 2222 (or any port above 1024 that isn't already in use) in sshd_config, and remember to update any firewall rules and your SSH client's connection shortcuts to match. This is a convenience/noise-reduction measure, not a real security boundary on its own — pair it with key-based auth, not instead of it.

Step 3: Install and Configure Fail2ban

Fail2ban watches your auth logs and temporarily bans IP addresses that show repeated failed login attempts, which matters even after disabling password auth because it also catches and blocks the connection-flood noise from scanners probing your SSH port.

sudo apt update && sudo apt install fail2ban sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

In jail.local, under the [sshd] section, set:

SettingReasonable ValueEffect enabledtrueTurns the sshd jail on maxretry3–5Failed attempts allowed before a ban bantime3600 (1 hour) or higherHow long an offending IP stays banned findtime600Window of time the maxretry count is measured over

Restart with sudo systemctl restart fail2ban and check status with sudo fail2ban-client status sshd to confirm it's actively monitoring.

Step 4: Don't Forward Port 22 (or Any SSH Port) Directly to the Internet

If you need remote access to a Pi from outside your home network, port-forwarding SSH directly on your router is the riskiest way to get it, because it puts the Pi's SSH daemon directly in the path of internet-wide scanning instead of behind any additional layer. A WireGuard VPN back into your home network, or Raspberry Pi Connect (the official browser-based remote access tool, which tunnels out rather than requiring an inbound open port), both avoid exposing SSH to the open internet at all. If you genuinely need direct SSH access from outside, changing the external port (not just the internal one) and keeping fail2ban and key-only auth in place reduces but doesn't eliminate the exposure.

Step 5: Keep the System Updated

SSH hardening doesn't help if an unrelated service on the Pi has an unpatched vulnerability that gets you root anyway. Run sudo apt update && sudo apt full-upgrade on a regular cadence, and consider unattended-upgrades for security patches specifically if the Pi runs headless and you don't log in often enough to catch updates manually.

What This Doesn't Protect Against

Hardening SSH assumes the threat is someone trying to log in remotely — it does nothing against physical access to the SD card, a compromised device elsewhere on your network pivoting in, or a vulnerability in a different exposed service (a web dashboard, a database, a media server) running on the same Pi. Treat SSH hardening as one layer, not the whole security posture, especially on a Pi that's also running Home Assistant, Pi-hole, or anything else with its own network-facing interface.

None of these five steps requires specialized security knowledge, and together they take a Pi from "trivially brute-forceable by automated bots within hours" to "a meaningfully harder target that most opportunistic scanning will simply bounce off of." Do steps 1 and 3 at minimum on every Pi you ever expose to a network you don't fully control, including your own home Wi-Fi if it has guest devices or IoT gear you don't fully trust.