Linux VPS First Steps: 10 Things to Do After You Receive Your Server

You have just received the IP address and root password of a new Linux VPS. Before you install a website or an application, take an hour for ten basic steps: safer logins, updates, a firewall, brute-force protection, the correct time, backups and monitoring. This guide gives the standard commands for Ubuntu and Debian and for AlmaLinux and Rocky Linux, the distributions listed on the Linux VPS plan page.

Before you start: the server is now yours to run

A VPS comes with full root access, and with it full responsibility. Under EngHosting's acceptable use policy, once the login details are delivered, the server's files, settings, updates and protection are the customer's responsibility, and managing the server from the inside is a separate service. If nobody on your team is comfortable on the command line, decide now whether you will learn these steps or arrange that management service.

In the commands below, replace SERVER_IP with your server's address and deploy with the username you choose. Steps 1 to 3 run as root; from step 4 onwards, add sudo in front of administrative commands.

Quick reference: the two Linux families

Step 1: Log in and change the root password

Linux, macOS and current versions of Windows all include an SSH client. Connect with ssh root@SERVER_IP and accept the server's key fingerprint on the first connection. Then run passwd and set a long, new root password, even though you will soon stop using it for remote logins. Keep it in a password manager, not in an email or a chat.

Step 2: Update everything and automate security updates

• Ubuntu / Debian: apt update && apt upgrade -y
• AlmaLinux / Rocky Linux: dnf upgrade -y

Reboot once with reboot if the update installed a new kernel. Then make security patches install themselves: on Ubuntu and Debian, install unattended-upgrades and enable it with dpkg-reconfigure --priority=low unattended-upgrades; on AlmaLinux and Rocky Linux, install dnf-automatic, set apply_updates = yes in its configuration file, and enable it with systemctl enable --now dnf-automatic.timer. Fixes for known vulnerabilities usually appear soon after they are disclosed, and automation means they do not wait for you to log in. Keep major version upgrades manual.

Step 3: Create a normal user with sudo rights

• Ubuntu / Debian: adduser deploy then usermod -aG sudo deploy (on a minimal Debian image, install sudo first with apt install sudo)
• AlmaLinux / Rocky Linux: useradd -m deploy, passwd deploy, then usermod -aG wheel deploy

Automated attacks always try the username root, working as root all day lets one mistyped command damage the whole system, and a named sudo user leaves a clearer trail of who did what.

Step 4: Switch to SSH key login

On your own computer, run ssh-keygen -t ed25519 and protect the private key with a passphrase; the private key never leaves your device. Copy the public key to the server with ssh-copy-id deploy@SERVER_IP on Linux or macOS. Windows does not include ssh-copy-id, so log in as the new user, create the folder with mkdir -p ~/.ssh, paste the contents of your id_ed25519.pub file into the authorized_keys file inside it, then fix the permissions with chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys. Open a new terminal and confirm that ssh deploy@SERVER_IP logs you in without asking for the account password.

Step 5: Lock down SSH

Open the SSH configuration with sudo nano /etc/ssh/sshd_config and set PermitRootLogin no and PasswordAuthentication no. Also look at the files in the sshd_config.d folder next to it, because a setting placed there, for example by the provisioning system, can take precedence over the main file. Check the syntax with sudo sshd -t (no output means it is valid), then restart the service: sudo systemctl restart ssh on Ubuntu and Debian, or sudo systemctl restart sshd on AlmaLinux and Rocky Linux.

Keep your current session open and test a fresh login from a second window; if it fails, you can still fix the file from the connected session.

Step 6: Turn on the firewall

Open only the ports you actually serve: SSH, plus 80 and 443 if the server will host websites. Allow SSH before enabling the firewall, or you will lock yourself out.

• Ubuntu / Debian (on Debian, install it first with sudo apt install ufw): sudo ufw allow 22/tcp, sudo ufw allow 80/tcp, sudo ufw allow 443/tcp, then sudo ufw enable and check with sudo ufw status.
• AlmaLinux / Rocky Linux: if firewalld is not running, install it with sudo dnf install firewalld and start it with sudo systemctl enable --now firewalld. SSH is already allowed in the default zone; add the web ports with sudo firewall-cmd --permanent --add-service=http and the same command for https, then apply with sudo firewall-cmd --reload.

Never open database ports such as 3306 or 5432 to the internet. Applications on the same server reach the database locally.

Step 7: Block brute-force attempts with Fail2ban

A server with SSH open starts receiving automated password guesses soon after it goes online. Fail2ban watches the logs and temporarily bans addresses that fail repeatedly. Put your own settings in jail.local rather than editing jail.conf, which package updates overwrite.

• Ubuntu / Debian: sudo apt install fail2ban. The SSH jail is enabled by the distribution's defaults. If the service fails to start because no auth.log file exists, add backend = systemd under the [sshd] section of jail.local.
• AlmaLinux / Rocky Linux: enable EPEL with sudo dnf install epel-release, install with sudo dnf install fail2ban, create jail.local with an [sshd] section containing enabled = true, then run sudo systemctl enable --now fail2ban.

Confirm it is working with sudo fail2ban-client status sshd.

Step 8: Set the time zone, time sync and hostname

Run timedatectl to see the current time zone and whether the clock is synchronised. To keep logs and scheduled jobs in Egyptian time, use sudo timedatectl set-timezone Africa/Cairo; many administrators keep servers on UTC instead, which is fine as long as you stay consistent. Using a zone name rather than a fixed offset lets the system follow daylight-saving changes on its own. If the clock is not synchronised, install chrony, which is available on all four distributions. Accurate time matters for logs, cron jobs, certificates and signed API requests. Finally, give the server a recognisable name with sudo hostnamectl set-hostname vps1.example.com.

Step 9: Set up backups that live off the server

EngHosting's acceptable use policy makes customers responsible for regular backups of their data, especially without a backup plan, so build this on day one rather than after the first incident.

• What: application files, database dumps made with mysqldump or pg_dump, the configuration in /etc, and a note of what you installed.
• Where: storage separate from the VPS. The extra services page lists annual backup storage plans.
• How: a scheduled job (cron or a systemd timer) running a tool such as rsync, restic or BorgBackup, with encryption for anything leaving the server.
• Proof: restore to a test location every few months.

How often to run it and how long to keep copies is covered in our automatic backup scheduling guide.

Step 10: Add basic monitoring

Learn four quick checks: uptime for load, free -h for memory, df -h for disk space and journalctl -p err -b for errors since the last boot. Then add two alerts that work while you sleep: an external uptime check that tests your site or service from outside the server, and a warning when the disk passes about 80% full. A full disk silently stops databases and logging, and it is one of the most avoidable outages on a VPS.

After the ten steps

Now install your stack: web server, language runtime and database. Add an SSL certificate, since none is listed on the VPS plan cards: a free certificate through Certbot, or a DV, OV or EV certificate from the SSL certificates page. On the entry plan with 2 GB of RAM, a small swap file gives a safety margin during memory spikes. Keep a short text log of every change you make; it will save hours later.

Still choosing a plan or distribution? Read how to size a Linux VPS plan for your workload. If your software only runs on Windows, see when you need a Windows VPS and how to connect by RDP.

Useful links: Shared Hosting, Linux VPS, Domain Registration, Contact Us.