First 24 Hours on a New VPS: Updates, Firewall and Users Step‑by‑Step

Why the First 24 Hours on a VPS Matter

When you power up a brand‑new VPS, it usually comes in a very open, very generic state. Packages may be a few months out of date, the firewall is often disabled, and you are dropped straight into the server as the all‑powerful root user. That combination is perfect for speed during installation, but terrible for long‑term security and reliability. The first 24 hours are your chance to shape this blank machine into a hardened, predictable environment that you trust with your projects, clients and data.

In this guide we’ll walk through a practical, opinionated checklist that we also apply on our own infrastructure at dchost.com: fully updating the system, creating safe user accounts, setting up SSH keys, locking down root access, configuring a basic firewall, and adding a few protective layers like automatic updates and brute‑force protection. You don’t need to be a Linux expert; we’ll explain each step in simple terms, with copy‑and‑paste commands you can adapt for your distribution. By the end of this first day, your VPS will be far closer to “production‑ready” than most servers ever are.

Step 1: Connect Safely to Your New VPS

Gather your access details

After ordering a VPS from us at dchost.com, you’ll receive (or see in your control panel) key information:

• Server IP address (IPv4, and often IPv6)
• SSH port (usually 22, unless you customised it)
• Root username (often root)
• Root password or SSH key, depending on what you chose

Keep these somewhere safe. You’ll use them only for the initial connection and for emergencies later; routine work will move to a non‑root user.

Connect from your computer via SSH

SSH (Secure Shell) is the standard secure way to manage a Linux VPS. On macOS and Linux you can use the built‑in terminal; on Windows 10+ you can use Windows Terminal or PowerShell.

From macOS/Linux terminal or Windows PowerShell:

ssh root@YOUR_SERVER_IP

If your VPS uses a non‑standard SSH port, include it:

ssh -p 2222 root@YOUR_SERVER_IP

On first connect, SSH shows a message like “The authenticity of host can’t be established…”. This is normal for a new server; verify you’re connecting to the correct IP from your dchost.com panel, then type yes to trust it.

Immediately change the root password

If your server was provisioned with a password, change it right away to something strong and unique:

passwd

You’ll be prompted to enter the new password twice. Use a password manager, not something you can easily memorise.

If the server was provisioned with SSH keys only, you can skip this, but it’s still good practice to ensure root login is later disabled over SSH (we’ll do that in a later step).

Step 2: Fully Update the Operating System

Fresh VPS images are often a few weeks or months behind on package updates and security fixes. Before you install anything, bring the entire system up to date so you’re building on a clean base.

Debian / Ubuntu: Update with apt

apt update
apt upgrade -y

On some systems you may also see apt dist-upgrade recommended to handle kernel and dependency changes. If prompted to restart services, accept the defaults. After a major kernel update, reboot:

reboot

AlmaLinux / Rocky / Other RHEL‑like: Update with dnf or yum

dnf update -y

or on older systems:

yum update -y

Again, reboot if the kernel is updated:

reboot

Install essential tools

After reconnecting (now to the updated system), install some baseline tools that make day‑to‑day work easier:

# Debian/Ubuntu
apt install -y vim htop curl wget git unzip

# AlmaLinux/Rocky/RHEL
dnf install -y vim htop curl wget git unzip

You can replace vim with nano if you prefer.

Set timezone and basic system identity

Correct time is crucial for logs, SSL certificates and security tools.

timedatectl list-timezones | grep Europe
sudo timedatectl set-timezone Europe/Istanbul

Replace with your actual timezone. Verify:

timedatectl status

Also check the hostname, which appears in prompts and logs:

hostnamectl status
hostnamectl set-hostname myproject-vps-1

Use something descriptive, especially if you plan to manage multiple servers through your dchost.com account.

Configure automatic security updates (optional but recommended)

Most distributions support some form of automatic security updates. On Debian/Ubuntu:

apt install -y unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

Enable at least automatic security patches. For more advanced TLS and protocol tuning later, you can refer to our detailed guide on SSL/TLS security updates and what to keep in sync on your servers.

Step 3: Create a Non‑Root User and SSH Keys

Running everything as root is convenient but dangerous. If any command or application is compromised, an attacker immediately has full control of the machine. Instead, use an unprivileged user, and grant it sudo (admin) rights only when needed.

Create a new user

Choose a username that matches who will use the server, for example deploy or your own name.

adduser deploy

Follow the prompts for password and optional details (you can leave those blank). Then add the user to the sudo or wheel group:

# Debian/Ubuntu
usermod -aG sudo deploy

# AlmaLinux/Rocky/RHEL
usermod -aG wheel deploy

Test the user by switching to it:

su - deploy

Then test sudo:

sudo whoami

If everything is configured correctly, it should output root after you enter the user’s password.

Generate SSH keys on your local machine

SSH keys are safer and more convenient than passwords. They use a pair of cryptographic keys: one private key that stays on your computer, and one public key that you upload to the server.

On your laptop/desktop (not on the VPS), generate a key pair:

ssh-keygen -t ed25519 -C "my-laptop-key"

Press Enter to accept the default path (usually ~/.ssh/id_ed25519) and set a strong passphrase when asked.

This creates:

• Private key: ~/.ssh/id_ed25519 (keep this secret)
• Public key: ~/.ssh/id_ed25519.pub (safe to share with servers)

Add your public key to the new user

Still on your local machine, copy the public key to the server:

ssh-copy-id deploy@YOUR_SERVER_IP

If ssh-copy-id is not available, you can manually copy the contents of id_ed25519.pub and paste into the server:

# On the VPS as root (or via sudo)
mkdir -p /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys

Paste the public key line, save and exit, then fix permissions:

chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Now, from your local machine, test logging in as the new user:

ssh deploy@YOUR_SERVER_IP

If it logs in without asking for the user’s password (but may ask for your key passphrase), SSH keys are working.

If you want to go further and use hardware security keys or an SSH certificate authority later, we’ve written a deeper, practical guide to VPS SSH hardening with FIDO2 keys and safe key rotation.

Disable direct root and password logins in SSH

Once you can log in as the non‑root user with SSH keys, lock down SSH so that:

• Root cannot log in directly
• Password‑based logins are disabled for everyone

On the VPS, edit the SSH config as root (or with sudo):

sudo nano /etc/ssh/sshd_config

Find and update (or add) the following lines:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

If you plan to allow some password logins temporarily, change only PermitRootLogin to no first, test, and then later disable passwords entirely when you are confident with keys.

Optionally, you can also change the default SSH port:

Port 2222

If you do, remember to adjust firewall rules (next step) and update your SSH commands accordingly.

Restart SSH to apply changes:

sudo systemctl restart sshd

Open a new terminal window and confirm you can still log in with your key. Only after verifying should you close the original root session.

Step 4: Set Up a Simple but Solid Firewall

A firewall controls which network ports are reachable from the internet. By default, your VPS may accept connections on many ports that you never intend to use. We want a very simple rule set for the first 24 hours:

• Allow SSH (your chosen port)
• Allow HTTP (80) and HTTPS (443) if you are hosting websites
• Deny or drop everything else by default

Ubuntu/Debian: Use UFW (Uncomplicated Firewall)

On Ubuntu, UFW is often installed out of the box, but not always enabled.

sudo apt install -y ufw

Allow SSH first (adjust if you changed port):

sudo ufw allow 22/tcp   # or your custom port

If you plan to host websites:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then set default policies and enable:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Check the status:

sudo ufw status verbose

Always ensure your current SSH port is allowed before enabling the firewall; otherwise you can lock yourself out.

AlmaLinux/Rocky/RHEL: Use firewalld

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld

Allow SSH and web traffic:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

For a non‑standard SSH port, open it explicitly:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Planning for nftables and more advanced setups

Once you’re comfortable with the basics, you may want to move beyond UFW/firewalld and use nftables directly for fine‑grained rules (rate limiting, port knocking, IPv6 tuning, etc.). When you reach that stage, our cookbook on building nftables firewalls for VPS servers will help you move step‑by‑step without drama.

Step 5: Add Basic Protection Against Brute‑Force Attacks

Even on a completely empty VPS, you’ll see constant automated login attempts on SSH within minutes of going online. With keys and a firewall you are already in a good position, but adding a tool like Fail2ban gives you an extra safety net by blocking IPs that repeatedly fail to authenticate.

Install Fail2ban

# Debian/Ubuntu
sudo apt install -y fail2ban

# AlmaLinux/Rocky/RHEL
sudo dnf install -y fail2ban
sudo systemctl enable --now fail2ban

Configure a simple SSH jail

Create a local configuration file so your changes are not overwritten by updates:

sudo mkdir -p /etc/fail2ban/jail.d
sudo nano /etc/fail2ban/jail.d/ssh.conf

Example minimal config (assuming SSH on port 22):

[sshd]
enabled  = true
port     = ssh
logpath  = /var/log/auth.log
maxretry = 5
findtime = 600
bantime  = 3600

On RHEL‑like systems the SSH log path is often /var/log/secure, so adjust accordingly.

Restart Fail2ban:

sudo systemctl restart fail2ban

Check status:

sudo fail2ban-client status sshd

Over time you’ll see banned IPs accumulate. This is normal; it shows Fail2ban is actively blocking repeated failed logins.

If you later build more complex stacks with web application firewalls or CDN‑side protection, you can combine those with host‑level protections. For example, our article on layered WAF and bot protection using Cloudflare, ModSecurity and Fail2ban together shows how these tools complement each other in real‑world setups.

Step 6: Log, Monitor and Baseline Your VPS

The first 24 hours are also a good time to create a “before anything runs” baseline, so you can later spot when something is off.

Check basic system logs

System logs live primarily under /var/log. A few important ones to glance at after your initial setup:

• /var/log/auth.log or /var/log/secure – SSH logins, sudo activity
• /var/log/syslog or /var/log/messages – general system messages
• journalctl -xe – recent systemd errors and warnings

Spend a few minutes checking for repeated errors or suspicious entries. This helps you get used to normal noise levels so anomalies stand out later.

Baseline CPU, disk and network performance

While not strictly security‑related, a quick benchmark in the first 24 hours gives you a reference for your VPS’s health over time. If, months later, everything becomes slow, you’ll know what “fast” looked like on day one. We’ve covered this in detail in our guide on what to test when you buy a new VPS (CPU, disk and network benchmarking).

Plan simple monitoring and alerts

Even a tiny setup benefits from basic monitoring. At minimum, consider:

• Uptime monitoring (HTTP checks to your site)
• CPU, RAM, disk usage and network traffic graphs
• Alerts for high load, low disk space or service failures

When you are ready to go beyond “log in and check manually”, our practical starter guide to VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma walks through a simple, modern setup that still fits on a single VPS.

Step 7: Enable IPv6 and Network Hygiene (If Available)

Many modern VPS plans at dchost.com include IPv6 connectivity. Enabling and testing it on day one prevents headaches later, especially as global IPv6 adoption keeps climbing.

Check IPv6 connectivity

From your VPS, run:

ip addr | grep inet6

If you see a global (non‑fe80::) IPv6 address, you’re likely good. Test outbound connectivity:

ping6 google.com

If that works, also ensure your firewall rules cover IPv6 as well as IPv4. UFW and firewalld support both; just confirm that v6 rules are enabled.

For a more detailed, end‑to‑end walkthrough, we have a dedicated article on IPv6 setup and configuration on a VPS server, including DNS AAAA records and practical real‑world checks.

Step 8: Checklist Recap for the First 24 Hours

Let’s summarise the core tasks you should aim to complete on day one:

1. Connect securely: Use SSH, verify host key, immediately change the root password if applicable.
2. Update the OS: Run full package upgrades, install essential tools, set timezone and hostname.
3. Create a non‑root user: Add a normal user, grant sudo/wheel access, test sudo.
4. Set up SSH keys: Generate keys locally, add the public key to your user, test key‑based login.
5. Lock down SSH: Disable root SSH login, consider disabling password logins, optionally change the SSH port.
6. Configure a firewall: Use UFW or firewalld to allow SSH and web ports, deny everything else.
7. Add brute‑force protection: Install and configure Fail2ban for SSH (and later, web services).
8. Review logs and baseline performance: Check system logs for errors, run a simple benchmark.
9. Enable IPv6 (if available): Confirm connectivity, ensure firewall rules cover IPv6.

This may look like a long list, but in practice, once you get used to it, most of these steps can be completed in under an hour. The security and stability benefit you gain is far greater than the time investment.

Beyond Day One: Where to Go Next

After the first 24 hours, you’ll move from “make the VPS safe” to “make it serve real workloads”. That means installing your web stack (Nginx/Apache, PHP, Node.js, databases), configuring HTTPS certificates, setting up backups, and building proper deployment workflows. We’ve covered many of these topics across the dchost.com blog, from deeper VPS security hardening to stack‑specific tuning for WordPress, Laravel and more.

The important thing is that you now start from a known‑good, hardened baseline: updates applied, firewall in place, SSH locked down, and basic protection against automated attacks. Every minute you invest at this stage makes your later architecture decisions easier and your incidents rarer.

If you’re planning your next project, or looking to move up from shared hosting, our VPS plans at dchost.com are designed with this workflow in mind: clean images, up‑to‑date kernels, IPv6 support and data centres optimised for real‑world hosting. Combine that with the checklist you’ve just followed, and you’ll have a solid, professional foundation for whatever you build next—without turning your first 24 hours on a new VPS into a stressful experience.