SSH (Secure Shell) lets people log in to a machine remotely over an encrypted connection. It is very useful, and a favorite target, so a secure configuration matters. Do these steps only on your own practice VM and keep a snapshot.

The configuration file

The SSH server (sshd) reads /etc/ssh/sshd_config. Always back it up before editing, and test the syntax before you restart:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
sudo sshd -t                      # checks the file for errors
sudo systemctl restart ssh        # service may be named sshd on some systems

Keep a second terminal logged in while you test, so a mistake cannot lock you out. If SSH is not required by the scenario, the best hardening step is to disable it entirely with sudo systemctl disable --now ssh.

Key settings

Lines starting with # are comments, so make sure the setting you want is uncommented. Recommended values for a typical practice image:

PermitRootLogin no            # no direct root logins
PermitEmptyPasswords no       # never allow blank passwords
PasswordAuthentication yes    # set to no only after SSH keys work
PubkeyAuthentication yes
MaxAuthTries 3                # fewer guesses per connection
LoginGraceTime 30             # seconds to log in
X11Forwarding no              # unneeded graphical forwarding
Protocol 2                    # only matters on very old OpenSSH
ClientAliveInterval 300       # drop idle sessions
ClientAliveCountMax 2
AllowUsers alex               # only list users who really need SSH
LogLevel VERBOSE              # more detail for auditing

Why these matter: root is the most guessed username, so refusing it removes an easy target; limited tries slow down guessing; and AllowUsers creates a short allowlist so other accounts cannot use SSH even if they exist. Newer OpenSSH versions remove the old protocol options, so run sshd -t and read any warnings.

Using keys instead of passwords

Keys are stronger than passwords. On your own client and VM:

ssh-keygen -t ed25519            # create a key pair
ssh-copy-id alex@practice-vm     # install the public key on the server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Test that key login works before you turn off PasswordAuthentication. Also check ~/.ssh/authorized_keys for keys you do not recognize; an unexpected key is an unauthorized way in.

Verifying and monitoring

  • sudo sshd -T | grep -i permitroot prints the settings the server actually uses.
  • sudo ss -tlnp | grep sshd confirms which port is open.
  • Review /var/log/auth.log for failed logins (previous lesson).
  • Make sure UFW allows SSH only if needed, ideally with ufw limit 22/tcp.

Changing the port from 22 only hides the service from casual scans; it is not a substitute for the settings above.

Check your understanding

Which setting stops people from logging in directly as root over SSH?

  • PermitRootLogin no
  • X11Forwarding no
  • LogLevel VERBOSE
  • MaxAuthTries 10

Answer: PermitRootLogin no Users should log in as themselves and then use sudo for administration.

What should you run after editing sshd_config and before restarting SSH?

  • sudo sshd -t
  • sudo reboot
  • sudo rm sshd_config
  • ls /tmp

Answer: sudo sshd -t It checks the file for syntax errors so a typo does not break SSH.

Why keep a second terminal open while changing SSH settings?

  • It makes SSH faster
  • You can fix the configuration if the change locks you out
  • It is required by OpenSSH
  • It logs out other users

Answer: You can fix the configuration if the change locks you out An already-open session stays connected even if the new settings reject new logins.

What does AllowUsers alex do?

  • Gives alex root access
  • Allows only alex to log in through SSH
  • Deletes other users
  • Opens port 22 to everyone

Answer: Allows only alex to log in through SSH It creates an allowlist so unlisted accounts cannot use SSH.

PreviousNext