Securing access to Ubuntu step by step

Choose how you will connect to the system and the chapter shows the steps in the right order, from the admin account and SSH to the firewall, Tailscale, 2FA and Fail2Ban. You can combine several ways of connecting; steps they do not need are skipped. Works for Ubuntu Server and for Ubuntu Desktop that also serves as a server.

Vladimír NeporAuthorVladimír Nepor
Published

Your choice

The choices are stored only in your browser and also adjust the "next step" bar in the individual guides.

System type
How will you connect to the system?

The remote ways B, C and D can be combined. The chapter shows the steps for all selected. A (locally only) excludes them.

Without a choice all steps are shown. Once you choose, steps you do not need are greyed out.

Ubuntu Desktop as a server

A desktop goes to sleep by default. To keep it running continuously, disable sleep and hibernation:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

To revert: sudo systemctl unmask … with the same units.

Your details: the commands in this guide are filled in from them. They are stored only in your browser and other Ubuntu guides use them too.

Your admin account (with sudo) created during the Ubuntu installation. Not root and not common names like admin, ubuntu or user. Bots try those first.

Invalid value, the commands keep the placeholder.

IP address in your local network (see your router or run ip -4 addr on the server), a Tailscale address or a domain name.

Invalid value, the commands keep the placeholder.

Optional change of the default port 22. It reduces log noise; real protection comes from key login and the firewall. Range 1024 to 49151.

Invalid value, the commands keep the placeholder.

Address range of devices connected to the same router as the server. E.g. 192.168.1.0/24 means all addresses 192.168.1.1 to 192.168.1.254. It is filled in from the server address. Fill it in only if your range differs.

Invalid value, the commands keep the placeholder.

Steps

Logging in

  1. Not logged in as root

    Ways: A always · B always · C always · D always

    Look at the command prompt after logging in. Does it start with your name and end with $ (<ADMIN_USER>@…:~$)? Then everything is fine. Continue with the next step. If you are logged in as root (root@…:~#), expand the steps below.

    I am logged in as root (typically a server from a provider)

    Create your own account with sudo rights and from then on work only under it. Pick an unusual name, bots mostly try admin, ubuntu or user.

    adduser <ADMIN_USER>
    usermod -aG sudo <ADMIN_USER>

    Log out and log in as the new user. The SSH step then disables root login over SSH; when needed, you switch to root with sudo -i.

    Why not root: every Linux has a root account, so an attacker only needs to guess the password. With your own unusual name they have to guess the name too, and every sudo is logged together with the user.

  2. Disabling the SSH server

    Ways: A yes · B no · C no · D no

    Without remote access you do not need an SSH server. What does not run cannot be attacked. Ubuntu Desktop does not have it by default; if which sshd prints nothing, there is nothing else to do. Otherwise disable it:

    sudo systemctl disable --now ssh.socket ssh     # Ubuntu 24.04 and newer
    sudo systemctl disable --now ssh                # Ubuntu 22.04

    Or remove the package: sudo apt purge openssh-server. Verification: the output must be empty: sudo ss -tlnp | grep -E 'sshd|:22 '

  3. Installing the SSH server

    Ways: A no · B yes · C yes · D yes

    Directly on the server (monitor and keyboard) check that the SSH server is installed. Ubuntu Server has it if you selected Install OpenSSH server during installation; Ubuntu Desktop does not by default.

    which sshd

    If it prints a path (/usr/sbin/sshd), it is installed. Empty output means it is missing. Install it:

    sudo apt update && sudo apt install openssh-server
    SSH packages
    • openssh-server: to connect to this machine (needed on the server).
    • openssh-client: to connect from this machine elsewhere (the ssh command); usually preinstalled.
    • ssh: installs both.

    Check that SSH is listening (the output contains :22): sudo ss -tlnp | grep -E 'sshd|systemd'. The address for the Server address field is shown by ip -4 addr (the inet line of the network interface, not 127.0.0.1).

  4. Key login and SSH hardening

    Ways: A no · B yes · C yes · D yes

    Key-only login, no password and no root. Settings in a separate file /etc/ssh/sshd_config.d/00-hardening.conf, optionally a different port. The key is only as safe as the computer it is stored on, see protecting the key and the computer.

    Open the guide: Key login and SSH hardening →

  5. Two-factor authentication (2FA)

    Ways: A no · B optional · C optional · D recommended

    Adds a one-time code from your phone to the key. It matters most for a server reachable from the internet (D) or for sudo. With SSH only over Tailscale the benefit is smaller.

    Open the guide: Two-factor authentication (2FA) →

Network access

  1. Firewall (UFW)

    Ways: A always · B always · C always · D always

    The UFW firewall is installed in Ubuntu but disabled and filters nothing. Everything listening on the server is then reachable from the network; on a fresh Ubuntu that is practically just SSH (sudo ss -tulpn lists it, lines with 127.0.0.x are local only). So enable the firewall before you add more services (database, web, Docker). On a server with a public IP, SSH is visible from the internet right after installation. Finish the Key login step there first.

    We deny all incoming traffic and allow only what your chosen ways of connecting need. Add the SSH rule before ufw enable, otherwise you lock yourself out.

    sudo ufw default deny incoming
    sudo ufw default allow outgoing

    For A

    No SSH rule, enable the firewall right away.

    For B, C

    We allow SSH only from devices in your home network: computers and phones connected to the same router as the server. The network is written as an address range (<LAN_SUBNET>); it is filled in automatically from the server address.

    How to check the range on the server
    ip -4 route show proto kernel

    The range is the first item on the line where the server address follows the word src (e.g. the line … dev enp86s0 proto kernel scope link src …). Lines with docker0 or tailscale0 are not your home network. If the range differs from the one in the command below, enter it into the Home network field.

    For B

    Permanently allow SSH from the home network:

    sudo ufw allow from <LAN_SUBNET> to any port 22 proto tcp comment 'SSH from LAN'

    For C (only without B)

    You will set up Tailscale from the home network, so allow SSH from it temporarily for now. The Tailscale step removes this rule once it works:

    sudo ufw allow from <LAN_SUBNET> to any port 22 proto tcp comment 'SSH from LAN (temporary)'

    For C

    The Tailscale step adds a rule for the tailscale0 interface.

    For D

    SSH from anywhere, with rate limiting (limit = at most 6 connections per 30 s from one address):

    sudo ufw limit 22/tcp comment 'SSH'

    Enable and check:

    sudo ufw enable
    sudo ufw status verbose

    Mind Docker: ports published by a container bypass UFW, see Docker on Ubuntu Server.

  2. SSH over Tailscale

    Ways: A no · B no · C yes · D no

    A private network between your devices. SSH is then allowed only on the tailscale0 interface and fully closed to the internet, with no open ports on the router. In the local network the connection goes directly, nothing slows down.

    Open the guide: SSH over Tailscale (in Czech) →

  3. Brute-force protection (Fail2Ban)

    Ways: A no · B optional · C optional · D yes

    Temporarily blocks addresses with repeated failed login attempts. Required for SSH reachable from the internet. When SSH is only in the local network or over Tailscale, brute-force attacks hardly reach the server.

    Open the guide: Brute-force protection (Fail2Ban) →

Need a secure server setup?

We design, secure and document networks and servers.

Servers & Networks