How to Setup a Dedicated Server: First Steps After Provisioning

The provisioning email arrives. You have an IP address, a root password, and a freshly installed operating system sitting on enterprise hardware in a data centre. What happens next determines whether that server becomes a reliable production asset or a liability. Knowing how to setup a dedicated server correctly in the first hour matters far more than most teams realise, because a server with a public IP address begins receiving automated connection attempts almost immediately after it comes online.

Those probes are not targeted. Scanners sweep entire IP ranges continuously, cataloguing hosts with open ports, and brute-force tools are then pointed at whatever they find. A newly provisioned server running default configurations is precisely what they are looking for.

The pattern is well recognised by the agencies that study it. In their joint advisory on the ten most common cybersecurity misconfigurations, the NSA and CISA place default software configurations and improper separation of user and administrator privilege at the top of the list, the two conditions that a freshly provisioned server exhibits by definition. This guide closes both, in the order that matters.

Why the First Hour Is the Riskiest

A default operating system installation prioritises accessibility over security. SSH accepts password authentication. Root login is permitted. No firewall rules restrict inbound traffic. These defaults exist so the server is reachable immediately after provisioning, and they are exactly the conditions that automated attacks exploit.

The asymmetry favours the attacker. Defenders must block every attempt, whereas an attacker needs one success. Nor does that attacker need particular skill: a credential list and a script suffice, because the tooling has been commoditised for over a decade.

What follows a successful login is worse than the login itself. Attackers who gain shell access typically move to establish persistence quickly, adding their own public key to the authorized_keys file, creating an additional account, or installing a backdoor. Once that happens, revoking the original compromised credential no longer removes their access.

Consequently, the first hour is not about deploying your application. It is about closing the window before anyone walks through it. The mitigations that NSA and CISA recommend, removing default credentials, hardening configurations, disabling unused services, restricting administrative privilege, and automating patching, describe almost exactly the sequence below.

Step 1 – Connect and Change the Root Password

Your provider issues a root password over email or a control panel. Treat that password as compromised from the moment it left their system, because it travelled through infrastructure you do not control.

Connect over SSH and change it immediately:

$ ssh root@your.server.ip
$ passwd

Choose something long and random rather than clever. This password will exist for perhaps twenty minutes before you disable password authentication entirely, but it protects the window in which you are still configuring the server.

Step 2 – Update Everything Before Anything Else

The operating system image your provider installed was built at some point in the past. Between that build date and your provisioning date, security patches accumulated. Apply them before installing a single application:

$ apt update && apt upgrade -y    # Debian, Ubuntu
$ dnf upgrade -y                  # AlmaLinux, Rocky Linux

A reboot may be required if the kernel updated. Do it now, while the server is empty and downtime costs nothing. Rebooting a production server later, under pressure, is an entirely different experience.

Step 3 – Create a Non-Root User with Sudo

Working as root is convenient and dangerous. A mistyped command executes with unlimited privilege, and any process you launch inherits that privilege. Improper separation of administrative privilege is, as the NSA and CISA advisory notes, among the most consistently exploited weaknesses in real environments.

$ adduser yourname
$ usermod -aG sudo yourname     # Debian, Ubuntu
$ usermod -aG wheel yourname    # AlmaLinux, Rocky Linux

Before logging out of your root session,

open a second terminal and verify that the new account can log in and run sudo -v successfully. Locking yourself out of a freshly provisioned server is a common and avoidable mistake, and the reason IPMI or remote console access exists.

Step 4 – Configure SSH Key Authentication

This is the single highest-leverage action in the entire setup process. A password can be guessed. A correctly generated SSH key cannot be brute-forced within any meaningful timescale.

Generate a key pair on your local machine, not on the server:

$ ssh-keygen -t ed25519 -C "your@email.com"
$ ssh-copy-id yourname@your.server.ip

Test the key-based login in a separate terminal before proceeding. Once confirmed, harden the SSH daemon by editing the configuration file:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Reload the service with sudo systemctl reload sshd. From this moment, credential brute-force attacks against your server are irrelevant. The scanners will keep knocking; nobody is answering.

Moving SSH from port 22 to a non-standard port reduces automated scanning noise substantially, although it offers no protection against a determined attacker who scans the full port range. Treat it as log hygiene rather than security.

Step 5 – Establish a Default-Deny Firewall

By default, every port on which a service listens is reachable from the entire internet. A firewall inverts this: nothing is reachable unless you explicitly permit it.

$ ufw default deny incoming
$ ufw default allow outgoing
$ ufw allow OpenSSH
$ ufw allow 80/tcp
$ ufw allow 443/tcp
$ ufw enable

Notice the order. SSH is permitted before the firewall is enabled, because switching on a default-deny policy without an SSH exception disconnects you instantly from a server you have no other way to reach.

Only open ports that a service genuinely requires. A web server needs 80 and 443. It does not need a database port exposed publicly, bind the database to localhost instead, and let the application reach it over the loopback interface.

Step 6 – Install Automated Intrusion Blocking

Even with password authentication disabled, automated tools will continue hammering your SSH port indefinitely. Fail2ban reads authentication logs, identifies IP addresses generating failed attempts, and blocks them at the firewall level.

$ sudo apt install fail2ban
$ sudo systemctl enable --now fail2ban

The default configuration bans an IP address for ten minutes after five failed attempts. For a production server, tightening the threshold and extending the ban duration is worthwhile, an address that has already failed three times is not a legitimate user who mistyped their password.

Fail2ban does not replace key authentication. Rather, it reduces log noise, blunts distributed attacks, and buys time. Layer it on top of proper authentication instead of relying on it alone.

Step 7 – Set Up Automatic Security Updates

Known vulnerabilities with public exploits are the most common path to compromise, which is why automating patching, with priority given to known exploited vulnerabilities, appears explicitly among the NSA and CISA mitigations. Automation removes the human failure mode of forgetting.

$ sudo apt install unattended-upgrades
$ sudo dpkg-reconfigure --priority=low unattended-upgrades

Configure it to apply security updates only, not feature updates, and to email you when a reboot becomes necessary. Automatic patching of security packages carries low risk; automatic patching of everything does not.

Step 8 – Configure Backups Before You Have Anything to Lose

Backups feel unnecessary on an empty server. That impression is precisely why teams postpone them until after the first data loss.

Establish the backup mechanism now, while the process is simple and the stakes are low. Whatever you choose: rsync to a remote host, a snapshot service, or a dedicated backup tool, verify that a restore actually works. An untested backup is a hypothesis, not a safeguard.

Then automate it, monitor the automation, and alert on failure. A backup job that silently stopped running three months ago is functionally identical to no backup at all.

Step 9 – Install Monitoring and Alerting

You cannot respond to a problem you cannot see. Basic monitoring covers CPU, memory, storage, network throughput, and service availability, with alerts routed somewhere a human will notice them.

Netdata provides comprehensive metrics with essentially no configuration. Prometheus paired with Grafana offers more control and longer retention. Either is adequate; running nothing is not.

Additionally, configure alerts for disk space. Running out of storage ranks among the most common and most avoidable causes of production outages, and it announces itself hours in advance if anyone is watching.

Step 10 – Document What You Built

The final step produces no visible change to the server and is the one most consistently skipped.

Write down the SSH port, the firewall rules and why each exists, the location of the backup destination, the monitoring endpoints, and the accounts holding administrative access. Store this somewhere that is not the server itself.

Six months from now, when a service fails at an inconvenient hour, this document is the difference between a ten-minute fix and a two-hour archaeology exercise. Moreover, it is what allows a colleague to help when you are unavailable.

What to Expect When You Setup a Dedicated Server

The steps above take between ninety minutes and three hours for someone comfortable with Linux administration, and rather longer for someone doing it for the first time. That investment happens once per server.

However, the sequence matters more than the speed. Steps one through five close the window that automated attacks exploit, and they should be complete before the server has been online for an hour. Steps six through ten build the operational foundation, and they can proceed at a more considered pace once the immediate exposure is closed.

Above all, resist the temptation to deploy your application first and secure the server afterwards. The scanners do not wait for you to finish.

Frequently Asked Questions

How long does it take to set up a dedicated server?

What is the first thing to do after provisioning a new server?

How quickly do attackers find a new server?

Should I disable root login on a dedicated server?

Do I need a firewall if my dedicated server has SSH keys configured?

Which Linux distribution should I install on a new dedicated server?