Secure your SSH server

An SSH server is a door into your computer. By the end of this lesson you can make it accept keys only, limit it to your own network, see who has signed in, and change its settings without locking yourself out.

Who knocks on the door

On a home LAN, anything on your Wi-Fi can reach port 22: family devices, guests, a cheap smart plug with old software. If the server is ever reachable from the internet, automated scanners try common usernames and passwords on it all day.

Each step on this page closes one way in:

Risk	What stops it
Someone guesses or steals a password	Keys only: passwords are not accepted at all
Someone signs in as root and owns everything	No root sign-in
Devices you do not know can reach the door	A firewall that allows your LAN only
A bug in old software	Updates
A key you forgot about still works	Reviewing authorized_keys and sign-in logs

Before you change anything

A mistake in the SSH server's settings can stop it accepting anyone, including you. Follow these rules every time:

• Be able to reach the computer without SSH: its own keyboard and screen, or a cloud provider's web console.
• Keep one SSH session open while you make changes. Restarting the SSH server does not end sessions that are already open, so this one is your way back.
• Test from a second, new connection before you close the first.
• Know how to undo it before you start.

Keys only

Do this only after key sign-in works. Check that ssh maya@192.168.1.20 signs you in without asking for the account password (lesson 3).

The main settings file is /etc/ssh/sshd_config. Do not edit it. On Ubuntu, it starts by reading every file in /etc/ssh/sshd_config.d/ that ends in .conf, so put your changes in a small file of your own. Updates leave it alone, and undoing it means deleting one file.

1. Create the file:

   sudo nano /etc/ssh/sshd_config.d/10-keys-only.conf

2. Put these three lines in it, then save and close:

   PasswordAuthentication no
   KbdInteractiveAuthentication no
   PermitRootLogin no

3. Test the settings before using them:

   sudo sshd -t

   No output means no errors. A typo is reported with the file and line:

   /etc/ssh/sshd_config.d/10-keys-only.conf: line 3: Bad configuration option: PermitRootLogn
   /etc/ssh/sshd_config.d/10-keys-only.conf: terminating, 1 bad configuration options

   Never restart the server while sshd -t reports an error.

4. Check the settings the server will really use:

   $ sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'
   permitrootlogin no
   passwordauthentication no
   kbdinteractiveauthentication no

5. Apply them:

   sudo systemctl restart ssh

6. Keep this session open. From another terminal or device, check that a password is now refused:

   $ ssh -o PubkeyAuthentication=no maya@192.168.1.20
   maya@192.168.1.20: Permission denied (publickey).

   Then check that your key still works with a normal ssh maya@192.168.1.20.

Setting	What it does
PasswordAuthentication no	Passwords are not accepted
KbdInteractiveAuthentication no	Closes the other route that can ask for a password
PermitRootLogin no	Nobody can sign in as root, even with a key. Sign in as yourself and use sudo.

To undo it, from the session you kept open or at the computer itself:

sudo rm /etc/ssh/sshd_config.d/10-keys-only.conf
sudo systemctl restart ssh

Why the file name starts with 10

For most settings, the SSH server uses the first value it reads, and it reads the files in sshd_config.d in alphabetical order. Some cloud images ship a file such as 50-cloud-init.conf that turns passwords back on. A name starting with 10- is read before it, so your setting wins. sshd -T in step 4 shows which one won.

On Windows, the settings file is C:\ProgramData\ssh\sshd_config. Add PasswordAuthentication no above any Match lines in it, then run Restart-Service sshd in PowerShell as administrator. The same rules apply: keep a session open and test from a new one.

Allow only your own network

A firewall can make the SSH server unreachable from anywhere except your LAN. On Ubuntu with ufw, add the rule first, then turn the firewall on:

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       192.168.1.0/24

Use your own LAN's range from ip -brief address (lesson 1). Turning on ufw over an SSH connection warns that it may disrupt existing SSH connections; with the rule in place first, yours stays up. Everything else that arrives from the network is now dropped, which also protects other servers on the machine, such as a running mock.

On Windows, installing OpenSSH Server added an inbound firewall rule. To allow it on private networks only, run this in PowerShell as administrator:

Set-NetFirewallRule -Name OpenSSH-Server-In-TCP -Profile Private

Keep it up to date

Most real break-ins use known bugs in old software. On Ubuntu:

sudo apt update && sudo apt upgrade

Ubuntu also installs security updates by itself in the background (the unattended-upgrades package), but run updates yourself now and then and restart when asked. On Windows, keep Windows Update turned on.

See who signs in

The SSH server writes every sign-in, and every failed attempt, to the system log:

journalctl -u ssh --since today

Lines to look for:

Accepted publickey for maya from 192.168.1.35 port 51544 ssh2: ED25519 SHA256:…
Failed password for maya from 192.168.1.77 port 40112 ssh2
Invalid user admin from 192.168.1.77 port 40120

The first is you, from your phone. The other two are someone trying passwords and guessing usernames from another device on your network: find out which device has that address. last lists recent sign-ins, and who lists who is signed in right now.

Do not leave it running for nothing

An SSH server you forgot about is the easiest one to break into. If you only need SSH now and then, turn it off between uses. On Ubuntu 22.10 and later:

sudo systemctl disable --now ssh.socket ssh.service

And on again when you need it:

sudo systemctl enable --now ssh.socket

Other habits for a machine that others could reach while you are away:

• Remove keys you no longer use from authorized_keys, and unpair machines you no longer use in CrossShell.
• Do not leave remote desktop running when nobody is watching the screen.
• Lock the computer's screen and the phone that holds your keys.

Stay safe

Habits for when your laptop or phone is on a network you do not control, such as a café, a hotel, an airport or a conference:

• Never accept an unchecked host-key fingerprint, and stop at a changed-key warning. Public Wi-Fi is exactly where a machine in the middle is most likely.
• Mark the network as Public on Windows, and refuse firewall prompts for public networks.
• Turn off what listens. Stop mock servers, development servers and your laptop's own SSH server, or have ufw turned on.
• Hide from nearby devices. In NearShare, turn off Visible to nearby devices; see Visibility and background.
• Keep tunnels on 127.0.0.1: never turn on Allow other devices to use it in SecureShell Go here.
• Reach home through a VPN, not through ports opened on your router.

Check yourself

QuizSecure your SSH server

Question 1 of 6

You are about to turn off password sign-in on a server you reach over SSH. What should you do first?

Score: 0

What you learned

• Put your own settings in /etc/ssh/sshd_config.d/10-….conf, not in the main file.
• PasswordAuthentication no, KbdInteractiveAuthentication no and PermitRootLogin no make a keys-only server with no root sign-in.
• Always run sudo sshd -t before restarting, keep one session open, and test from a new one.
• A firewall rule for your LAN range keeps everyone else away from port 22.
• journalctl -u ssh shows who signed in and who tried; turn the server off when you do not need it.

Next steps

• Lab: your own SSH server
• Verify host keys in SecureShell Go
• Troubleshooting and FAQ for SecureShell Go