If you’ve rented a standard VPS server - rather than a Managed VPS, which we’ll discuss another time - it usually comes with a fairly basic set of initial credentials, such as an IP address, username, and password. At this point, from a technical standpoint, the server is already up and running. But in essence, it can’t yet be called a fully-fledged server, since right now it’s more of a blank canvas for a real server.
Very often, novice administrators, immediately after receiving the server, start installing Nginx, Docker, or a control panel on it, or rush to migrate their website right away. But it’s far more important to spend the first half-hour on the basic setup of your new VPS, because if you perform just a few simple steps in the correct order, this will significantly reduce the likelihood of the server being hacked, losing access to it, and encountering unpleasant surprises after launching your project.
That’s why, in this article, we’ll walk you through setting up a new, completely clean virtual server step by step from scratch - from your first login all the way to a production-ready state. Everything described below applies to most VPS servers running Ubuntu, Debian, AlmaLinux, or Rocky Linux.
Reconnaissance
Before taking any action, it’s worth documenting the initial state of the server you’ve been assigned - specifically, you need to note which OS is installed, how much memory and disk space are available, and which processes are already listening on network ports.
cat /etc/os-release hostnamectl free -h df -h ss -tulpn
The last command is particularly useful, since a fresh VPS may not necessarily be completely empty - the provider’s image might include SSH, cloud-init, a virtualization agent, or additional software. If any service is already accessible from the network, it’s best to find out now.
While you’re at it, check the server’s time as well; if the time and time zone are set incorrectly, cron won’t run when expected, and the timestamps in the logs will no longer match. You can do this with the following command:
timedatectl
Check the Network and DNS
The next step is to verify that the VPS has received the expected IP address assigned by your provider. You can also check the route to the Internet and ensure that the DNS servers are working.
ip addr ip route ping getent hosts
The ip addr command will display your network devices along with their assigned IP addresses. The ip route command should show a default route through the provider’s gateway. Using the ping command, you can verify network connectivity, for example, by pinging a remote server on the Internet. The easiest way to check DNS functionality is with this query:
getent hosts example.com
Update the System
Even a fresh Linux image doesn’t necessarily mean that all the installed packages are up to date, since some time may have passed between the creation of the template and the launch of your VPS - during which new security patches may have been released. Therefore, when you first start the server, you should immediately update the system to the latest version.
For Ubuntu and Debian:
apt update && apt upgrade -y
For AlmaLinux and Rocky Linux:
dnf upgrade -y
In Ubuntu and Debian, you can check whether a reboot is required after the update using the following command:
test -f /var/run/reboot-required && cat /var/run/reboot-required
If the kernel or other critical components have been updated, it’s best to reboot the server immediately; after rebooting, make sure your VPS is back online
Later on, it will be helpful to set up automatic installation of security updates. In Debian and Ubuntu, unattended-upgrades is used for this, while RHEL-compatible systems use the dnf-automatic tool. At the same time, it’s best to keep a full system update a controlled operation and perform it manually.
Create a separate administrator account
Of course, working as root all the time is very convenient, since the system never returns a Permission denied error. But this is also where the great danger lies, since any erroneous command is executed with the highest privileges and can lead to irreparable consequences, including the complete deletion of the system and data from the disk.
To create a separate user in Ubuntu or Debian, use the following commands:
adduser adminuser usermod -aG sudo adminuser
In AlmaLinux and Rocky Linux:
useradd -m adminuser passwd adminuser usermod -aG wheel adminuser
You can check a specific user’s groups with the command:
id adminuser
After that, day-to-day work is performed from a regular user account, and administrative commands are run only via sudo.
Set up SSH, but be careful not to lose access to the server
The root password - especially one provided by your ISP - should never be used as the primary method of logging into the server. For ongoing work, it’s more convenient and secure to use SSH keys.
To do this, on the computer you’ll use to connect to the server in the future, generate an RSA key pair using the command:
ssh-keygen -t rsa -b 4096
By default, two files will be created:
~/.ssh/id_rsa ~/.ssh/id_rsa.pub
id_rsa is the private key; it remains on your computer. You only need to transfer the public key id_rsa.pub to the server:
ssh-copy-id -i ~/.ssh/id_rsa.pub adminuser@SERVER_IP
If ssh-copy-id is not available, then output the public key to the console:
cat ~/.ssh/id_rsa.pub
Copy the resulting string and add it to the ~/.ssh/authorized_keys file on the server. If the directory and file do not yet exist, run the following commands:
mkdir -p ~/.ssh chmod 700 ~/.ssh nano ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys
Now open a second terminal and verify that you can log in using the RSA key you created:
ssh -i ~/.ssh/id_rsa adminuser@SERVER_IP
After logging in, verify that sudo works:
sudo whoami
The command should return root. Only after key-based login has been verified can you disable direct SSH login for root and password-based authentication. To do this, in the file /etc/ssh/sshd_config or in the files /etc/ssh/sshd_config.d/*.conf, locate and set the following parameters:
PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes
Before applying the changes, be sure to check the configuration with the command:
sshd -t
You can view the current SSH settings using the command:
sshd -T
You can also change the default port 22, but this shouldn’t be considered a strong security measure. Of course, there will be fewer random login attempts, but specialized scanners will still find the SSH service even on a different port.
That’s why it’s much more useful to set up key-based authentication and disable password-based authentication - which is exactly what we’ve just done.
Close Unnecessary Ports
After configuring SSH, it’s a good idea to restrict network access to the server itself. Even on a brand-new VPS, there may be services running that don’t need to be accessible from the internet, and their number will only grow over time.
First, determine which ports your server actually needs. For example, SSH must accept connections from the administrator, and a future web server will need HTTP and HTTPS. Databases, Redis, or internal services generally don’t need public access at all.
Therefore, the easiest way to configure the new server’s firewall is to follow the principle: everything that isn’t explicitly allowed is blocked.
For Ubuntu and Debian, it’s convenient to use UFW (Uncomplicated Firewall), which is already built into the system. First, allow SSH so you don’t lose connection to the server, and only then enable the firewall:
ufw allow OpenSSH ufw allow 80/tcp ufw allow 443/tcp ufw enable ufw status verbose
If the web server isn’t installed yet, ports 80 and 443 can be opened later.
In AlmaLinux and Rocky Linux, firewalld is typically used:
firewall-cmd --permanent --add-service=ssh firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https firewall-cmd --reload firewall-cmd --list-all
After configuration, check again which services are listening on the network:
ss -tulpn
The firewall and this command show different sides of the same picture. The firewall determines which traffic is allowed, while ss shows which applications are actually accepting connections.
For a typical web server, the situation usually looks something like this:
|
Service |
Internet Access |
|---|---|
|
SSH 22 |
Yes |
|
HTTP 80 |
Yes |
|
HTTPS 443 |
Yes |
|
MySQL 3306 |
Usually no |
|
PostgreSQL 5432 |
Usually no |
|
Redis 6379 |
No |
|
Docker API 2375 |
No |
If the database is only needed by an application on the same VPS, then there’s obviously no need to make it accessible to the entire Internet.
Don’t forget about IPv6 either (if it’s even available on the service), so if a service is listening on the address [::], make sure the firewall rules protect IPv6 just as they do IPv4.
Check the server from the outside
A local check is certainly good, but it’s better to verify from the outside which ports are actually accessible from the internet on your server. To do this, from another computer, run the following command:
nmap SERVER_IP
After a short while, you’ll see in the console all the ports that are accessible on your server from the outside. As a result of these firewall settings, only the public services you actually intended to open should remain accessible.
Do You Need Fail2ban?
Even after disabling password-based login, SSH remains accessible from the Internet, which means automated connection attempts will appear in the logs fairly quickly. You can reduce this traffic using the Fail2ban utility.
Fail2ban monitors system logs for specific patterns and blocks IP addresses that generate too many failed login attempts within a short period of time. This is a useful addition to your existing SSH keys and firewall, but you shouldn’t rely on it alone.
In Ubuntu and Debian, you can install Fail2ban with the command:
apt install fail2ban -y
In AlmaLinux and Rocky Linux, the package is available via EPEL:
dnf install epel-release -y dnf install fail2ban -y
After installation, start the service and add it to startup:
systemctl enable --now fail2ban
Now check which jails are active:
fail2ban-client status
If sshd is among them, check its status separately:
fail2ban-client status sshd
There you’ll see failed login attempts and blocked IP addresses. It’s important to note that simply installing Fail2ban isn’t enough, since the specific jail for SSH must be enabled and actually working. For more details on configuring Fail2ban, read this article.
Check Memory, Swap, and Disk
On small VPS servers with minimal RAM, it’s often recommended to create a swap file right away. And sometimes this makes sense, since during a brief spike in memory usage, it can give the system some extra breathing room instead of immediately triggering the OOM killer.
However, you shouldn’t create a swap file by default; first, you need to assess the current state of your RAM and disk, as well as their usage, using the following commands:
free -h swapon --show df -h df -i
Here’s a guide to help you navigate:
|
Situation |
What to Do |
|---|---|
|
No swap, low RAM |
Consider adding swap |
|
Swap exists but is barely used |
This is normal |
|
Swap is constantly in use |
Check RAM usage |
|
OOM-killer terminates processes |
Investigate the cause or increase RAM |
It’s worth remembering that swap is not a full replacement for RAM, but merely a safety net in case of peak loads.
Checking inodes wouldn’t hurt here either, since the server may have gigabytes of free disk space but still be unable to create new files due to running out of inodes - for example, after accumulating millions of small cache files.
Check for Errors After Boot
So, you’ve completed the initial configuration and rebooted the server. Now your server is responding via SSH - that’s a good start, but it doesn’t necessarily mean the system booted without errors. After all, a service might not have started, and a hypothetical disk or network issue might simply not have manifested itself yet.
Two commands are enough for a quick check:
systemctl --failed journalctl -p err -b
The first will show services that terminated with an error. The second will display messages with a severity level of error or higher, but only for the current system boot.
Don’t be alarmed by every line in journalctl, as Linux logs often contain errors that don’t interfere with the server’s operation at all. First and foremost, you should pay attention to failed services, recurring messages, and errors related to the network, disks, or file systems.
Set Up Monitoring Before the First Outage
As long as your VPS is running normally, you may not even think about the need for monitoring. But if the server suddenly freezes, you’ll need to know what was happening with the CPU, memory, and disk a few minutes before the failure.
On a production server, you should at least monitor CPU load, RAM usage, free disk space, and the availability of the VPS itself. Of course, standard Linux tools are already available for real-time diagnostics, such as:
systemctl journalctl top
But these will only help you once you’ve already logged into the server and started troubleshooting the problem.
Therefore, for a production VPS, it’s better to set up external monitoring with notifications in advance. It will alert you when the server freezes or a service stops responding, and the system logs will help you figure out what happened beforehand. We wrote about one of the many monitoring tools - specifically, the Netdata system - in this article.
Set Up Backups
Sooner or later, your server will contain data whose loss would cost far more than the VPS itself. Therefore, it’s best to set up backups before migrating a website or launching a production application.
Exactly what to back up depends on the specific project and stack. For a typical website, this often includes files and the database; for Docker infrastructures, it includes volumes and container configurations. Sometimes it even makes sense to back up the entire virtual machine. By the way, 3v-Hosting does this for you completely free of charge, saving a daily snapshot of your virtual server from which you can restore the server in the event of a failure or data loss.
As you might guess, storing your only backup of important data on the same VPS is a very bad idea, because if the virtual disk becomes corrupted or the entire server becomes unavailable, your backup will be lost along with the original data. Therefore, at least one up-to-date copy should be stored outside the VPS.
Also, periodically try restoring data from the backup, since a successfully created archive does not guarantee that you’ll actually be able to restore a working project from it.
Perform a test reboot and get to work
That completes the basic setup. Before installing a website or other production software, you should check whether the server can handle a normal reboot with all the changes you’ve made. To do this, reboot the server with the command:
reboot
After the server boots up, reconnect via SSH and quickly check the VPS status:
uptime systemctl --failed ss -tulpn
Make sure the network and SSH are working, the necessary services have started, the firewall is active, and no unexpected ports have opened. If there’s a problem, it’s better to catch it now, while there’s still no live project on the server.
If you’re unable to access your server after the reboot, you can log in via the noVNC console in your 3v-Hosting account and analyze the situation from there to fix whatever went wrong.
After this check, you can use the VPS as intended - for example, to install a web server, Docker, a CMS, a VPN, or any other software you need.
However, never install programs just in case, since every extra daemon can open a new port, require updates, and add yet another configuration that you’ll have to monitor.
Checklist After First Login
Initial VPS setup shouldn’t turn into an endless security hardening process, as achieving perfection will be difficult and expensive. Therefore, your task boils down simply to removing dangerous default settings, blocking unnecessary access, and preparing the server for normal operation.
Ultimately, the entire process can be summarized in a short checklist:
- Check the OS, resources, time, network, and open ports;
- Install updates;
- Create a separate user with
sudo; - Set up SSH keys and verify login in a second session;
- Restrict root access and password-based authentication;
- Configure the firewall and check external ports;
- Install Fail2ban if necessary;
- Check RAM, swap, disk, and inodes;
- Check for failed services and review the system log;
- Set up monitoring and notifications;
- Set up external backups;
- Reboot the VPS and verify that everything is working;
- Only then should you install your production services.
Frequently Asked Questions About Initial VPS Setup
Do I need to change the SSH port 22?
This is not required. Using a different port will reduce the number of automated login attempts in the logs, but it is not a substitute for SSH keys, a firewall, and disabling unnecessary authentication methods.
Should I disable root login via SSH?
For a standard VPS, after creating a separate administrator account and verifying sudo, it’s best to disable direct SSH root login. However, do not close the old session until you’ve verified that the new login method is working.
Is Fail2ban necessary if password-based login is disabled?
No, it’s not required, but it can remain a useful additional layer of protection. Generally, its importance is significantly lower if SSH accepts only keys.
How much swap space does a VPS need?
There is no universal formula here, nor can there be, since its size depends on the amount of RAM and the server’s load. What matters more than a specific RAM-to-swap ratio is how the server actually uses its memory.
Which ports should be opened on a new VPS?
Only those necessary for the specific server. For a typical web server, these are SSH, HTTP, and HTTPS. It’s best not to open ports for databases, Redis, internal APIs, and other service components unless absolutely necessary.
Do you need to reboot the VPS after an update?
Not after every update. However, a reboot is required after updating the kernel and certain system components. During initial setup, it’s helpful to perform at least one test reboot to ensure the server is configured correctly.
Is it possible to install Docker or a control panel first and configure security later?
Technically, it’s possible, but this order is not recommended. The installed software may immediately open additional network ports and start new services. It’s easier to first set up a basic, secure VPS configuration and then add applications.
