Securing a new Linux server: what attackers try first

Put a server on the internet and something that is not you will try to log in to it. It will not be a person, and it will not know anything about you. It will be a program working through a list: the username root with the password 123456, then the next pair, then the next, on port 22 of your address and of every other address it can reach.

That is good news. A robot that tries the same things everywhere is beaten by the same few changes everywhere. Each step in this guide takes away one thing it needs: a password to guess, a root account to guess it for, a port to reach, the time to keep trying, or a bug that has already been fixed. Knowing which step removes which thing lets you ignore the folklore, and doing them in the right order keeps you from locking yourself out halfway.

What arrives first: robots with a word list

The SANS Internet Storm Center collects login attempts from honeypots: machines that offer SSH and Telnet, hold nothing of value, and record everything that tries to get in. Volunteers run the sensors, and logs from Cowrie, an SSH and Telnet honeypot, are accepted too.¹ Nobody has a reason to target these machines in particular, so what they record is the background every server on the internet receives, whether it is a production VPS or a staging copy someone set up on a Friday.

On 28 September 2026, the day's running totals showed 420,479 attempts to log in as root, more than four times the next name, admin, at 94,904. Then came ubuntu, user, system, enable, deploy, test and guest: names that exist on many servers by default or by habit. The most-tried password was 123456, ahead of strings such as 1234, 123, Password and admin.¹ The totals climb through the day, but in two snapshots taken hours apart, root, admin and ubuntu led both times.

Attempts at the username root on one day, SANS ISC sensors (28 September 2026, running total)

420,479

How far root led the next name, admin (420,479 / 94,904)

4.4x

The most-tried password the same day

123456

MITRE ATT&CK, a public catalogue of attacker techniques, files this under password guessing: an attacker with no valid credentials trying passwords systematically. SSH on TCP port 22 is the first entry in its list of commonly targeted services, followed by Telnet, FTP, SMB, RDP and others, including databases such as MSSQL, Oracle and MySQL on 3306.²

Guessing is the loudest thing that arrives, not the only one. The same robots look for any other port that answers, such as a database, a cache or a forgotten test page, and some traffic carries exploits for known bugs in whatever is listening, which work however good your password is. Guessing, exposure and old bugs are stopped by different layers, which is why the drawing at the top has more than one.

Your own user, and a key instead of a password

The commands in this guide are for Debian and Ubuntu; other distributions have the same pieces under slightly different names. Before you change anything, open your provider's browser console in a tab and keep this SSH session open until a fresh login works; the full lock-out-safe order is at the end of the guide. Start with an account of your own. On a default Ubuntu install, root has a password hash that matches no possible value, so root cannot log in directly, and administrators work through sudo instead, which leaves a record of who did what.¹² If your server came with a root password or a root key instead, the first job is to make the account you will use from now on. On Debian and Ubuntu, adduser creates it, and adding it to the sudo group gives it full root access through sudo.¹² Debian's installer adds the sudo package when it is given no root password,²⁴ so a server set up with one may not have it: install it first.

# apt install sudo# adduser alice# adduser alice sudo

Give the account a strong password even though SSH is about to stop accepting passwords. sudo will ask for it, and so will the provider's console on the day you need to log in without the network.

How a key login works

A password is a secret you send so the server can compare it with the one it stored. Anything that is sent can be guessed and sent again, which is all the robots do. SSH's public key method never sends the secret. The SSH standard makes holding the private key the proof: the client sends a signature made with its private key, and the server checks both that the key is allowed for that user and that the signature is valid.³ The private key stays on your computer. The server keeps only the public half, in the account's ~/.ssh/authorized_keys file, one key per line.⁶

For the robot, that removes the target. With passwords off there is no prompt to answer, so a list of every password ever leaked is worth nothing. It also covers the accounts you forgot about: the test user a colleague made with a weak password is as safe as root, because no account accepts a password over SSH at all.

Making a key and installing it takes two commands on your own computer. ssh-keygen with no arguments generates an Ed25519 key,⁷ the type Ubuntu's documentation recommends for its shorter keys and lower computational cost,¹¹ and ssh-copy-id puts your public key into the account on the server so that the server will accept it.⁸Give the key a passphrase when ssh-keygen asks. The private key is the one copy of your identity, and a passphrase means a stolen laptop does not hand it over.

$ ssh-keygen -t ed25519$ ssh-copy-id alice@203.0.113.10$ ssh alice@203.0.113.10

ssh-copy-id logs in with alice's password to do its work, so password logins have to still be on when you run it.⁸ If the server already accepts only keys, because you logged in as root with one, copy root's key file to the new account instead, as root on the server:

# install -d -m 700 -o alice -g alice /home/alice/.ssh# install -m 600 -o alice -g alice /root/.ssh/authorized_keys /home/alice/.ssh/authorized_keys

The last command should log you in without the account's password; a passphrase prompt, if any, is your key's own and is checked on your machine. Once in, sudo whoami should print root, and from then on root is not needed for logging in.

Telling sshd to stop asking for passwords

Having a key does not turn passwords off. Until the server's configuration changes, the robots can still try, and every account with a password is still a candidate. Four settings in sshd_config decide what they can try, and you change three of them.

The defaults in the table come from the sshd_config manual.⁴ Keyboard-interactive is the one people miss: a separate way for sshd to ask for a secret, often the account password, so turn both off. And a server image or an installer can change any default, so check the value in force rather than the one in the manual.

Why an edit sometimes does nothing

The most common surprise has a simple cause. For each keyword, sshd uses the first value it reads and ignores any later one.⁴ On Ubuntu the first line of sshd_config is an Include for every file in /etc/ssh/sshd_config.d/, so a setting in one of those files beats the same setting further down the main file,¹¹ and the included files are read in the order their names sort.⁴ A line added at the bottom of sshd_config loses to any snippet that set the same keyword first.

So put your settings in a file of your own in that directory, named to sort before anything already there, and let sshd tell you what it will really do. sshd -t checks the configuration file and keys without starting anything,⁶ and Ubuntu's documentation puts it before every restart, since losing SSH can mean losing your way to the server.¹¹ sshd -T goes further and prints the effective configuration: every keyword with the value that won.⁶

PasswordAuthentication noKbdInteractiveAuthentication noPermitRootLogin no

$ sudo sshd -t$ sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|pubkeyauthentication) 'permitrootlogin nopubkeyauthentication yespasswordauthentication nokbdinteractiveauthentication no$ sudo systemctl restart ssh

No output from sshd -t means no errors. Restarting is safe for the session you are typing in: sshd forks a separate process for each connection,⁶ so yours carries on while the listener restarts with the new settings. Before you close it, open a second terminal and log in fresh. If that works, the change is good. If it does not, you still have the first session to put things back.

Other settings that shape what a guesser gets

MaxAuthTries allows 6 authentication attempts per connection by default and starts logging failures once half of that is used. LoginGraceTime drops a connection that has not logged in within 120 seconds. AllowUsers, when set, lets only the named users log in at all, whatever else they present.⁴ OpenSSH 9.8 added PerSourcePenalties, on by default, which makes sshd refuse connections for a while from addresses that keep failing to authenticate;⁹ Debian 13's manual gives 5 seconds as the default penalty for a client that disconnects after failing.⁵Run sudo sshd -T | grep persourcepenalties to see whether your version has it. An empty result means it does not.

A firewall that says no unless you said yes

sshd can only look after SSH. Anything else listening on a public address meets the same robots, and plenty of software was written for a trusted network: a database that answers anyone on the network, a cache with no password, a dashboard started for a test. A host firewall deals with every port at once. In nftables, each base chain has a default policy, accept or drop, which decides what happens to a packet that no rule matched.¹³Set the input policy to drop and a port is closed unless a rule opens it. The list of what the internet can reach becomes the list you wrote, not the list of whatever happens to be running today. One common exception: ports published by Docker are routed before they reach the chains ufw manages, so a container published on 0.0.0.0 is reachable whatever ufw says.²⁷ Publish such ports on 127.0.0.1, and check with ss.

The nftables wiki's example ruleset for a server shows the whole pattern in a few lines.¹⁴Its input chain drops by default. It accepts packets that belong to connections already established, or related to them, and drops invalid ones. It accepts everything on the loopback interface, then opens the few ports the server offers, 22, 80 and 443 in the example. The output chain is left undefined, so outgoing traffic is allowed. The established rule is why a default-deny server can still install updates: the mirror's reply belongs to a connection the server opened.

ufw: the same pattern with less typing

ufw is Ubuntu's default firewall configuration tool, and it starts disabled.¹⁵It keeps one default policy per direction, and on installation the incoming policy is deny and the outgoing one is allow,¹⁶ so switching it on with a handful of allow rules gives you the pattern above. The trap is in the switching on. Turning ufw on rebuilds its chains from scratch, and that can cut the SSH session you are typing in; rules can be added while it is still off, so write the SSH rule before you enable it.¹⁶

$ sudo ufw default deny incoming$ sudo ufw default allow outgoing$ sudo ufw limit 22/tcp$ sudo ufw allow 80/tcp$ sudo ufw allow 443/tcp$ sudo ufw show addedAdded user rules (see 'ufw status' for running firewall):ufw limit 22/tcpufw allow 80/tcpufw allow 443/tcp$ sudo ufw enableCommand may disrupt existing ssh connections. Proceed with operation (y|n)? yFirewall is active and enabled on system startup

ufw show added lists the rules as you typed them, which is the list to read before you switch the firewall on, and adding --dry-run to a ufw command shows the changes it would make without making them.¹⁶¹⁵The SSH rule above uses limit rather than allow: connections get through until one address has started six within half a minute, and then that address is refused.¹⁶ The limit applies to you too: a deploy script or a burst of new terminals that opens six connections in half a minute is refused for a while, so use allow if you automate logins, or allow your own fixed address above it. If you always connect from a fixed address, such as an office or a VPN, you can go further and allow port 22 from that address only, as Ubuntu's firewall guide shows.¹⁵ Then the robots never reach sshd at all, and a change in your own address locks you out, so keep the console in mind.

Many providers also filter traffic before it reaches the server, but that filtering is aimed at floods, judged by volume and shape, and one address trying a password now and then looks like any other visitor to it. How DDoS protection works covers that layer. Everything in this guide happens on the server, and is yours to do.

fail2ban and rate limits: slower guessing, not an end to it

fail2ban watches login failures, in log files or the systemd journal, and when an address fails too many times it updates the firewall to reject new connections from it for a set time.¹⁷ Its shipped jail.conf bans an address for 10 minutes once it has failed 5 times within 10 minutes, and asks you not to edit it: your settings belong in jail.local or a file in jail.d, because an update can overwrite jail.conf.¹⁸ Upstream, every jail starts off. Debian's package switches the sshd jail on in jail.d/defaults-debian.conf and has it read the journal,²⁶ which matters because Debian 12 and later no longer install rsyslog by default, so there may be no /var/log/auth.log to read.²⁵ If you write the jail yourself, set the backend the same way; the systemd backend reads the journal.¹⁸

[sshd]enabled = truebackend = systemd

$ sudo apt install fail2ban$ sudo systemctl restart fail2ban$ sudo fail2ban-client status sshdStatus for the jail: sshd|- Filter|  |- Currently failed: 1|  |- Total failed:     38|  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd`- Actions   |- Currently banned: 2   |- Total banned:     9   `- Banned IP list:   203.0.113.45 198.51.100.23

The arithmetic for one address

Take one address guessing passwords against SSH, under four setups.

• Nothing in front. sshd allows 6 attempts per connection.⁴ On OpenSSH before 9.8 nothing in sshd caps the rate: the robot opens another connection whenever it likes. From 9.8, PerSourcePenalties refuses an address for 5 seconds after each failed connection once 15 seconds of penalty have built up,⁴⁹ roughly one failed connection every 5 seconds: 720 an hour at 6 tries each, about 4,300 guesses. A ceiling close to ufw's, and still far from zero.
• A ufw limit on port 22. An address that opens 6 or more connections in 30 seconds is denied, so it gets at most 5 connections per 30 seconds. At 6 tries each, that is 30 guesses per 30 seconds, and an hour holds 120 such windows: 30 × 120 = 3,600 guesses an hour, at most.
• fail2ban's defaults. After 5 failures the address is banned for 10 minutes. When the ban lifts, those failures are more than 10 minutes old and no longer count, so it gets another 5. That is about six rounds of 5 an hour, roughly 30 guesses, or 30 × 24 × 365 = 262,800 a year from that one address.
• Keys only. Zero, exactly: the server never asks for a password, so there is nothing for a guess to match.

Is 262,800 guesses a year a lot? Against a long random password, no. Twelve characters drawn from upper- and lower-case letters and digits give 62¹² combinations, about 3.2 × 10²¹; even at 3,600 guesses an hour, trying them all would take around 9 × 10¹⁷ hours. Against 123456, or a password that matches the account name, a year is far more than enough. And a robot network has many addresses, each with its own allowance. The fail2ban project is blunt about it in its own README: it makes wrong guesses rarer, but a weak password stays weak, and it points you to keys or two-factor login instead.¹⁷

Updates: the only fix for a bug in the lock itself

Every layer so far assumes the software doing the checking works. OpenSSH 9.8 fixed a race condition in sshd, present in Portable OpenSSH from version 8.5p1 to 9.7p1, that could allow arbitrary code execution as root. It had been demonstrated on 32-bit Linux systems with glibc, and in the lab an attack took 6 to 8 hours of continuous connections on average.⁹ Ubuntu's notice for the bug, CVE-2024-6387, describes an unauthenticated remote attacker triggering it by failing to authenticate within a set time.¹⁰No password was guessed and no key was needed. A server that accepted only keys was exposed until it was updated, because triggering the bug did not require logging in at all.

That is the job only updates can do. On Ubuntu, security updates are applied automatically by unattended-upgrades, which is installed by default and runs once a day, started by the apt-daily and apt-daily-upgrade timers with a random delay; /etc/apt/apt.conf.d/20auto-upgrades turns it on and off.¹⁹ Debian's unattended-upgrade does the same job, installing security upgrades from the configured package sources and logging to /var/log/unattended-upgrades/, and its --dry-run option simulates a run without installing anything.²⁰ Whether a particular image has it switched on is worth checking rather than assuming.

$ systemctl list-timers 'apt-daily*'$ cat /etc/apt/apt.conf.d/20auto-upgradesAPT::Periodic::Update-Package-Lists "1";APT::Periodic::Unattended-Upgrade "1";$ sudo unattended-upgrade --dry-run

If the file is missing, install the package with sudo apt install unattended-upgrades and set both values in 20auto-upgrades to "1"; a 0 switches that action off.¹⁹

Installed is not the same as running. A service keeps using the old copy of an updated library in memory until it restarts. From Ubuntu 24.04, unattended-upgrades hands that to needrestart, which restarts most affected services by itself, but automatic reboots are off by default.¹⁹ On Debian and Ubuntu, an update that needs a reboot leaves the file /var/run/reboot-required behind. A new kernel only runs after that reboot. Check for the file after updates and reboot at a quiet moment, or set Unattended-Upgrade::Automatic-Reboot to true with Automatic-Reboot-Time at an hour when nobody is using the server.

What is listening, and who has been knocking

A firewall can be switched off by mistake, so know what is behind it. ss lists sockets: -l shows only the listening ones, -t and -u pick TCP and UDP, -n prints numbers rather than service names, and -p shows the process behind each socket.²¹ Put together, they answer the question "what on this server accepts connections, and which program is it?"

$ sudo ss -tulpnNetid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Processudp   UNCONN 0      0         127.0.0.54:53        0.0.0.0:*    users:(("systemd-resolve",pid=512,fd=16))tcp   LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=801,fd=3))tcp   LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1204,fd=6))tcp   LISTEN 0      200        127.0.0.1:5432      0.0.0.0:*    users:(("postgres",pid=990,fd=7))tcp   LISTEN 0      511          0.0.0.0:6379      0.0.0.0:*    users:(("redis-server",pid=1110,fd=6))

Read the Local Address column. 127.0.0.1 (or [::1]) means only programs on this machine can connect, so the database line is fine. 0.0.0.0, [::] or * means every address the server has, the public one included. SSH and the web server are meant to be there. The cache on 6379 is the line to act on: stop it with sudo systemctl disable --now and its unit name, or tell it to listen on 127.0.0.1 in its own configuration. The firewall would have covered it; closing it at the source covers you on the day the firewall is off.

Reading the SSH log

On a server running systemd, the SSH log is in the journal. journalctl -u shows one unit, --since limits the time range, -f follows new entries as they arrive, and -g filters messages with a regular expression, ignoring case when the pattern is all lower case.²²On Ubuntu the unit is called ssh, the name its documentation restarts;¹¹ if that finds nothing on your distribution, try sshd.

$ sudo journalctl -u ssh --since today -g 'failed|invalid'Sep 28 09:14:02 web1 sshd[48211]: Invalid user admin from 203.0.113.45 port 51122Sep 28 09:14:05 web1 sshd[48213]: Failed password for root from 203.0.113.45 port 51130 ssh2$ sudo journalctl -u ssh --since today -g acceptedSep 28 10:02:41 web1 sshd[49870]: Accepted publickey for alice from 198.51.100.7 port 50214 ssh2: ED25519 SHA256:(fingerprint)

On OpenSSH 9.8 and later the process name in these lines is sshd-session rather than sshd.⁹ Failures are the background noise this guide started with, and once passwords are off they stop mattering. The line that matters is Accepted: every successful login, with the account, the method and the address. Any you do not recognise is worth acting on straight away. While you test a change, keep journalctl -u ssh -f running in one window and log in from another, and you will see exactly why a login was refused.

Beliefs that leave the door open

The last row is the layer for the day the others fail, and it gets one line here because it has a guide of its own: server backups that actually restore covers snapshots, database dumps, copies kept elsewhere and how to test a restore. None of this is a job you finish. NIST's guide to general server security treats it as controls to select, implement and then maintain,²³ and the commands in this guide are the maintaining: sshd -T, ss -tulpn and the journal are as useful next month as today.

The order that does not lock you out

Every step above can cut off your own access if it runs before the step it depends on. Two habits make the sequence safe. Never close the session you are working in until a fresh login has worked. And keep a way in that does not go through SSH or the network, such as a browser console in your hosting panel that shows the server's own screen.

1. 1

   Open the console, and keep one session open

   Open the server's console in a browser tab before you change anything, and leave your first SSH session open until the last step.

2. 2

   Update everything

   As root, run apt update, then apt full-upgrade (and apt install sudo if it is missing). If /var/run/reboot-required exists afterwards, reboot now, while nothing depends on the server yet.

3. 3

   Create your user and give it sudo

   adduser alice, then adduser alice sudo. Give it a strong password: sudo and the console will ask for it.

4. 4

   Install your key and prove it works

   Run ssh-copy-id from your computer (or copy root's authorized_keys if passwords are already off), log in as the new user from a new terminal, and check that sudo whoami prints root.

5. 5

   Turn off passwords and root logins

   Write your snippet in /etc/ssh/sshd_config.d/, run sudo sshd -t, read sudo sshd -T, restart ssh and log in again from a new terminal. A login with ssh -o PubkeyAuthentication=no should now be refused.

6. 6

   Add the firewall rules, then switch it on

   Deny incoming by default, limit 22, allow the ports your services need, read ufw show added, then run ufw enable and test a new login.

7. 7

   Add fail2ban

   Install it, make sure the sshd jail is on and reads the journal, restart fail2ban and check fail2ban-client status sshd.

8. 8

   Check that updates run by themselves

   Read 20auto-upgrades, look at the apt-daily timers, and decide how reboots will happen.

9. 9

   Close what you do not need, then back up

   Run sudo ss -tulpn and stop or rebind anything on every address that should not be there. Take a backup and restore it once, somewhere harmless.