Navigation

DevOps devops networking 5 min read

Hardening SSH Access

SSH (Secure Shell, the encrypted protocol you use to log into a remote Linux server from a terminal) is the front door to your server. The moment your server has a public IP address, automated bots start trying to guess usernames and passwords on it — thousands of attempts per day. Hardening SSH means closing the easy ways in: turning off password logins, blocking the all-powerful root account, and only allowing logins with cryptographic keys. This page shows you exactly how to do that safely on Ubuntu without locking yourself out.

Why default SSH is risky

A fresh Ubuntu server usually lets you log in with a username and password. Passwords can be guessed (a “brute-force attack” — trying millions of combinations until one works) or stolen. The root user is the superuser account that can do anything, so it is the first target attackers try. Leaving these defaults on is like leaving a key under the doormat.

The fix is to rely on SSH key authentication instead. An SSH key is a pair of files: a private key you keep secret on your laptop, and a public key you place on the server. They are mathematically linked, and the private key is far too long to ever guess. If you have not set this up yet, do that first — see SSH key authentication.

Do not skip ahead. Before you disable passwords, confirm you can log in with your key. If you turn off PasswordAuthentication without a working key, you will be permanently locked out of your own server and may have to rebuild it.

The main config file: /etc/ssh/sshd_config

All SSH server settings live in /etc/ssh/sshd_config on Ubuntu. This file controls the SSH daemon (a background service named sshd that listens for incoming connections). Editing it changes how the server accepts logins.

Open it with a text editor as the superuser:

sudo nano /etc/ssh/sshd_config

On Ubuntu 22.04 and 24.04 LTS, some settings also live in drop-in files under /etc/ssh/sshd_config.d/. Those files are read after the main file and can override it, so always check there too:

sudo ls -l /etc/ssh/sshd_config.d/

Output:

total 4
-rw-r--r-- 1 root root 173 Apr  9  2024 50-cloud-init.conf

Cloud providers often drop a 50-cloud-init.conf here that re-enables password login. If you set a value in the main file but it does not take effect, this drop-in is usually why.

Find the line for PermitRootLogin (or add it if missing) and set it to no. This means nobody can SSH in directly as root. You log in as your normal user and use sudo for admin tasks instead.

PermitRootLogin no

Step 2: Disable password authentication

Turn off password logins so only keys work. Check both the main file and the drop-in directory.

PasswordAuthentication no

To be safe, also override the cloud-init drop-in so it cannot undo your change:

echo "PasswordAuthentication no" | sudo tee /etc/ssh/sshd_config.d/99-hardening.conf

Step 3: Enforce key-only authentication

Make sure public-key login is explicitly allowed and that other weaker methods are off:

PubkeyAuthentication yes
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

KbdInteractiveAuthentication no blocks keyboard-interactive prompts, another path attackers can abuse. Keep UsePAM yes — Ubuntu needs it for account checks and session setup.

Step 4 (optional): Change the SSH port

By default SSH listens on port 22 (a “port” is a numbered channel on a server; see Ports and protocols). Moving it to a non-standard number hides you from the simplest bots that only scan port 22.

Port 2222

When to use this: it cuts log noise from automated scanners. When NOT to: it is not real security (“security through obscurity”). A determined attacker scans all ports anyway. Treat it as tidying, not protection. If you change the port, you must also open it in your firewall (see below) and connect with ssh -p 2222 user@server.

Setting	Default	Hardened value	Why
`PermitRootLogin`	varies	`no`	Stops direct attacks on the superuser
`PasswordAuthentication`	`yes`	`no`	Defeats password brute-forcing
`PubkeyAuthentication`	`yes`	`yes`	Allows secure key login
`KbdInteractiveAuthentication`	`yes`	`no`	Removes a weak login path
`Port`	`22`	optional	Reduces bot noise (not real security)

Step 5: Open the new port in the firewall first

If you changed the port, allow it in UFW (Uncomplicated Firewall, Ubuntu’s simple firewall front-end) before restarting SSH, or you will block yourself.

sudo ufw allow 2222/tcp
sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
2222/tcp                   ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere

Keep port 22 open until you confirm the new port works, then remove it with sudo ufw delete allow 22/tcp. See Firewall with UFW for more.

Step 6: Test the config, then restart sshd safely

First, validate your changes for syntax errors. This catches mistakes before they break the service:

sudo sshd -t

If it prints nothing, the config is valid. Now restart the daemon to apply changes:

sudo systemctl restart ssh

Keep your current session open. Do not close the terminal you are already connected through. Open a second terminal and try a fresh login: ssh -p 2222 youruser@your-server. If the new session works, you are safe. If it fails, your first session is still open so you can fix the config and restart again.

Output (successful new login):

Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-41-generic x86_64)
Last login: Sun Jun 15 10:22:14 2026 from 203.0.113.42
youruser@web-01:~$

Check the service is healthy:

sudo systemctl status ssh

Best Practices

Always set up and test SSH key login before disabling passwords.
Run sudo sshd -t after every edit to catch typos before restarting.
Keep one SSH session open and test logins from a second terminal.
Disable root login and use a normal user with sudo for admin work.
Check /etc/ssh/sshd_config.d/ for drop-ins that quietly re-enable passwords.
Open any new SSH port in UFW before restarting sshd.
Consider adding fail2ban (sudo apt install fail2ban) to auto-ban IPs that fail repeatedly.