First 30-minute dedicated server security checklist
A freshly delivered bare-metal server often has a public IPv4 address, an initial root password, and services that have not yet been reviewed. Treat the first login as a provisioning event: record the hardware, patch the operating system, create a non-root administrator, install SSH keys, restrict network access, and confirm that recovery access works.
This guide uses Ubuntu Server 22.04 or 24.04 LTS. Commands run as root unless stated otherwise. Keep your original SSH session open until you have tested a second session with the new administrator account. If your provider supplies IPMI, iDRAC, iLO, or another out-of-band console, confirm that it is reachable only through a VPN, allowlisted IP addresses, or a separate management network.
Prerequisites and minimum server requirements
- A dedicated server with Ubuntu Server 22.04 or 24.04 LTS installed.
- At least 4 physical CPU cores, 16 GB RAM, and 240 GB NVMe SSD for a small production server running a web application, monitoring stack, or several self-hosted services.
- A local computer with an SSH client, such as OpenSSH on Linux, macOS, or Windows PowerShell.
- Your server IPv4 address, initial root credentials, and console or remote-management access details.
- A stable static public IP address for your administration workstation if you plan to restrict SSH by source IP.
A VPS with 2 vCPU, 4 GB RAM, and 80 GB NVMe is enough for a low-traffic single service or a VPN endpoint. Choose dedicated or bare-metal hosting for sustained database activity, build runners, game servers, streaming, virtualization, or workloads requiring predictable CPU, disk I/O, and tenant isolation.
Choose hardware for the workload you will protect
Security controls use relatively little CPU, but log retention, backups, monitoring, databases, and application traffic determine production capacity. The figures below assume Linux, NVMe storage, daily backups to separate storage, and standard web application traffic.
Takeaway: start with 4 cores, 16 GB RAM, and 240 GB NVMe for up to about 50 active users, then increase RAM and NVMe capacity before a database or CI workload reaches sustained disk contention.
| Concurrent active application users | vCPU / CPU cores | RAM | Disk | Monthly bandwidth |
|---|---|---|---|---|
| Up to 50 users; small website, VPN, monitoring, or 1-2 self-hosted apps | 4 physical cores | 16 GB | 240 GB NVMe | 2 TB |
| 50-500 users; web app with PostgreSQL, mail relay, or small CI/CD runner | 8 physical cores | 32 GB | 480 GB NVMe | 5 TB |
| 500-3,000 users; database-backed platform, game nodes, streaming origin, or multiple build runners | 16 physical cores | 64 GB | 2 x 960 GB NVMe in RAID 1 | 10 TB |
1. Record the server state and apply updates
Log in using the delivery credentials and inspect the host before changing it. Save the output in your password manager or infrastructure documentation. Check the operating system, disk layout, active listeners, and available security updates.
hostnamectl
uname -a
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
free -h
ss -tulpn
apt update
apt full-upgrade -y
rebootAfter the reboot, reconnect and verify the host is running the expected kernel:
uptime
uname -r
apt autoremove --purge -yDo not install application packages before patching. A new image may contain fixes for OpenSSH, the Linux kernel, OpenSSL, sudo, or other exposed components.
2. Create a named administrator and install an SSH key
Daily administration should use a named account with sudo privileges, not the root account. On your local computer, generate an Ed25519 SSH key if you do not already have one:
ssh-keygen -t ed25519 -a 100 -C "[email protected]"From your local computer, copy the public key to the new account. Replace adminuser and SERVER_IP.
ssh-copy-id adminuser@SERVER_IPIf the account does not exist yet, create it on the server first:
adduser adminuser
usermod -aG sudo adminuser
install -d -m 700 -o adminuser -g adminuser /home/adminuser/.ssh
nano /home/adminuser/.ssh/authorized_keys
chmod 600 /home/adminuser/.ssh/authorized_keys
chown adminuser:adminuser /home/adminuser/.ssh/authorized_keysPaste one complete public key line into authorized_keys. Open a second terminal and test the new login before changing SSH settings:
ssh adminuser@SERVER_IP
sudo -v
whoamiThe final command should return root after sudo -i, or your account name without it. Do not proceed if key login fails.
3. Harden OpenSSH without losing access
Create a separate SSH drop-in configuration rather than editing the vendor file. This makes future package upgrades easier to review. The example keeps SSH on port 22; changing the port can reduce log noise but is not a substitute for key authentication and firewall restrictions.
cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers adminuser
EOF
sshd -t
systemctl reload sshKeep the existing session open. From a new terminal, verify that the key works and that root and password logins are rejected:
ssh -o PreferredAuthentications=publickey adminuser@SERVER_IP
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no adminuser@SERVER_IPThe password test should fail. If it does not, inspect the effective SSH configuration with:
sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers'4. Configure a default-deny firewall
UFW is suitable for a single dedicated server. Allow SSH first, then permit only ports used by services you actually intend to run. For a typical web server, TCP 80 and 443 are needed; PostgreSQL on port 5432 should normally remain private and must not be opened to the internet.
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verboseFor stronger management-plane protection, allow SSH only from your fixed office or VPN egress address. Add this rule before removing the broad SSH rule, and test from that approved network.
ufw allow from 203.0.113.25 to any port 22 proto tcp
ufw delete allow 22/tcp
ufw status numberedDocker-published ports can bypass expected UFW behavior because Docker adds nftables or iptables rules. Avoid publishing database, Redis, or administration ports with -p 0.0.0.0:PORT:PORT unless public access is required. Bind private services to 127.0.0.1 or an internal network and verify exposure with ss -tulpn.
5. Add brute-force protection and automatic security updates
SSH keys eliminate password guessing, but fail2ban still reduces repeated authentication attempts and protects future services such as Nginx basic authentication. Install fail2ban and enable its SSH jail:
apt install -y fail2ban unattended-upgrades
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF
systemctl enable --now fail2ban
fail2ban-client status sshdEnable unattended security updates, then review the generated policy. Automatic updates are useful for most single-purpose servers, but organizations with formal change windows should patch through their configuration-management process instead.
dpkg-reconfigure --priority=low unattended-upgrades
systemctl status unattended-upgrades --no-pager6. Protect the provider account, console, and DNS
Operating-system hardening cannot protect an attacker who can reset the server, mount its disks, alter reverse DNS, or access the remote console. Use a unique password and hardware-backed or authenticator-app MFA for the hosting control panel. Remove former staff accounts, restrict billing and server-reset permissions, and store recovery codes in an encrypted password manager.
For IPMI, iDRAC, or iLO, change the delivered management password immediately, install vendor firmware updates during a maintenance window, and do not expose its web interface publicly. If a private management VLAN is unavailable, access it through a WireGuard VPN or a source-IP allowlist.
7. Establish logging, time sync, and backups
Accurate time makes SSH, TLS, incident response, and log correlation possible. Confirm NTP synchronization and persistent journal storage:
timedatectl set-ntp true
timedatectl status
mkdir -p /var/log/journal
systemctl restart systemd-journald
journalctl --disk-usageBackups must be separate from the server being backed up. A RAID 1 mirror protects against one disk failure; it does not protect against deletion, ransomware, compromised root access, or an account-level error. At minimum, back up application data and configuration files daily to encrypted off-server storage.
apt install -y restic
export RESTIC_REPOSITORY='s3:https://OBJECT_STORAGE_ENDPOINT/server-backup'
export RESTIC_PASSWORD='replace-with-a-long-unique-secret'
restic init
restic backup /etc /home /var/www
restic snapshotsPlace repository credentials in a root-readable environment file or secret manager rather than shell history. Test restoration during the first week:
mkdir -p /root/restore-test
restic restore latest --target /root/restore-test
ls -la /root/restore-test/etc8. Verify the final security posture
Run these checks before deploying applications. They identify common mistakes such as an open database port, an inactive firewall, failed fail2ban service, or an SSH configuration that still allows root access.
ufw status verbose
ss -tulpn
systemctl --failed
fail2ban-client status sshd
sshd -T | grep -E 'permitrootlogin|passwordauthentication'
last -a | head
journalctl -p 3 -xb --no-pagerFrom an external network, scan only your own address to confirm that expected ports are exposed:
nmap -Pn -sV -p 22,80,443,5432 SERVER_IPA web server should normally show ports 22, 80, and 443 only. If port 5432, 3306, 6379, 2375, or a control panel port appears unexpectedly, stop the related service or restrict it to localhost or a private network.
Troubleshooting common first-day problems
SSH stopped working after hardening
Use the provider console or your existing open SSH session. Check syntax with sshd -t, inspect the loaded settings with sshd -T, and confirm that the public key exists in /home/adminuser/.ssh/authorized_keys. Correct ownership with chown -R adminuser:adminuser /home/adminuser/.ssh and permissions with chmod 700 /home/adminuser/.ssh && chmod 600 /home/adminuser/.ssh/authorized_keys.
UFW blocked administration access
Use out-of-band console access and run ufw status numbered. Add the correct source-specific rule, for example ufw allow from 203.0.113.25 to any port 22 proto tcp. Avoid disabling the firewall permanently; correct the rule and test a second SSH connection.
Fail2ban banned your office IP
Check the jail with fail2ban-client status sshd and remove the ban using fail2ban-client set sshd unbanip 203.0.113.25. Investigate the failed-login cause before adding your address to an ignore list.
Disk space fills after enabling logs or backups
Review usage with df -h, journalctl --disk-usage, and du -xhd1 /var | sort -h. Set journal retention, rotate application logs, and do not store backup archives only on the production server.