SSH Hardening with sshd_config

SSH is usually the one service on a server that the whole internet can reach, and automated scanners try it within minutes of a machine coming online. A few settings remove most of the risk, but each one can also lock you out if applied carelessly.

Keys instead of passwords

Password guessing is how most SSH compromises start. Turning off PasswordAuthentication leaves only public-key login, which cannot be guessed. Before you do, confirm in a second terminal that your key actually works, because turning passwords off with no working key leaves no way in.

PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey
PermitRootLogin no

The first value wins

sshd uses the first value it reads for each setting, and it reads files in /etc/ssh/sshd_config.d in alphabetical order. A cloud image often ships 50-cloud-init.conf containing PasswordAuthentication yes, so a hardening file named 99-hardening.conf is silently ignored. Name yours 00-hardening.conf, and make sure the Include line sits near the top of sshd_config, not the bottom.

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no

Apply it without locking yourself out

Check the syntax with sshd -t, reload instead of restarting so that your current session survives, then open a new connection in a second terminal and confirm it works before closing the first. If it fails, the old session is still there to undo the change. Changing the port needs the firewall opened for it before the reload.

sudo sshd -t
sudo systemctl reload ssh
# in a second terminal:
ssh -p 22 you@your-server

Limits worth setting

MaxAuthTries 3 cuts the number of guesses per connection, AllowUsers names the only accounts that may log in, and a ClientAliveInterval drops dead sessions. Forwarding of X11 and TCP are off unless you use them. Restricting key exchange, ciphers and MACs to modern ones helps, but stops very old clients from connecting.

Open the SSH hardening generator

Frequently asked questions

Is changing the SSH port worth it?

It reduces noise in your logs because most scanners try port 22, but it does not stop a determined attacker, who can scan every port. Treat it as housekeeping, not as a security control.

What is the difference between reload and restart?

Reload re-reads the configuration while leaving existing connections alone. Restart stops sshd and starts it again, which can drop your session if the new configuration has a problem.

How do I check what sshd is really using?

Run sudo sshd -T. It prints the effective value of every setting after all files are read, so you can see whether your drop-in or a distribution file won.

Guides

• Nginx Reverse Proxy Configuration
• Caddy Reverse Proxy Configuration
• Nginx Static Site Configuration
• Caddy Static Site Configuration
• Nginx + PHP-FPM Configuration
• Caddy + PHP-FPM Configuration
• Nginx SSL/TLS Configuration
• Nginx Load Balancer Configuration
• Caddy Load Balancer Configuration
• Nginx Rate Limiting Configuration
• Nginx Security Headers Configuration
• Caddy Security Headers Configuration
• Nginx Gzip Compression Configuration
• Nginx Caching Configuration
• Caddy HTTPS Redirect Configuration
• Nginx WebSocket Proxy Configuration
• Nginx Content-Security-Policy Header
• Block Bad Bots and Scanners in Nginx
• fail2ban for Nginx
• nginx.conf Best Practices
• Nginx Location Regex Tester
• Deploy Nginx Config with GitHub Actions
• Nginx CORS Headers Configuration
• Nginx Cache-Control Headers Configuration
• Nginx 301 Redirect Map Configuration
• robots.txt, Sitemap and security.txt
• Apache .htaccess Configuration
• Docker Compose and Dockerfile Configuration
• systemd Service and Timer Configuration
• Cron Expression Explainer
• SSH Hardening with sshd_config
• Linux Firewall Rules: ufw, nftables and iptables
• Glob Pattern Tester
• Analysing Nginx Access Logs with awk