After buying a VPS, you should not immediately install a website, database, or control panel. First, update the system, disable unnecessary login methods, configure the firewall, enable automatic updates, set up monitoring, and configure backups.
A secure sequence of steps looks like this:
- Connect to the server over SSH and update the packages.
- Set the server hostname and time zone.
- Create a separate user with sudo privileges.
- Add an SSH key and verify that you can log in as the new user.
- Disable direct root login and password authentication.
- Configure UFW and open only the ports that are actually required.
- Install Fail2ban to protect against credential brute-force attacks.
- Enable automatic installation of security updates.
- Check open ports, CPU load, RAM usage, and disk usage.
- Configure external backups or make sure the backup service is already enabled.
It is especially important to follow the correct order when configuring SSH. Do not disable root login or password-based login until key-based access for the new user has been verified in a separate session. Otherwise, you may lose access to the server.
The firewall should also not open all ports “just in case.” At the initial stage, SSH is usually enough, and the HTTP and HTTPS ports can be added before launching the web server. Databases, control panels, and internal services should not be exposed to the internet unless necessary.
Fail2ban and changing the default SSH port are not substitutes for key-based login, a firewall, and updates. They are additional layers of protection, not the foundation of security.
You should move on to installing a website only after the server has been updated, administrative access has been secured, unnecessary ports have been closed, monitoring is working, and backups are stored outside the VPS itself. This approach reduces the risk of compromise, data loss, and difficult recovery after the very first mistake.
It is worth noting separately that this material is intended primarily for those who are configuring a VPS for the first time and want to establish basic server protection before installing a website or application. It is not a substitute for a full security audit and does not account for all aspects of production infrastructure. For critical projects, it is better to involve a trusted system administrator or DevOps engineer. However, if that is not possible, the sequence of steps described here will help avoid the most common mistakes and prepare the server for further deployment.
First Login and System Update
Connecting to a VPS via SSH
After a VPS is created, the provider typically sends the server IP address, username, and authentication method. Depending on the image, this may be the root user, ubuntu, or another account with sudo privileges.
To connect from Linux, macOS, or Windows Terminal, use the command: ssh root@SERVER_IP
If the provider created a different user: ssh ubuntu@SERVER_IP
Replace SERVER_IP with the public IP address of the VPS. On the first connection, SSH will display the server fingerprint and ask you to confirm adding it to the list of known hosts. If possible, verify the fingerprint against the information in the provider’s control panel.
After logging in, it is useful to check the system version and basic server information:
cat /etc/os-release
hostnamectl
uptime
At this stage, you should not immediately install a web server, database, or control panel. First, bring the base system up to date.
Updating Packages and Rebooting
The VPS image may have been prepared several days, weeks, or even years ago, so after your first login you should update the package index and install any available updates:
apt update
apt upgrade -y
If you did not connect as root, run the commands with sudo:
sudo apt update
sudo apt upgrade -y
After the update, you can remove packages that are no longer required: sudo apt autoremove -y
You can check whether a reboot is required as follows: test -f /var/run/reboot-required && echo "Reboot required"
If the system indicates that a reboot is required: sudo reboot
The SSH connection will close. After a few seconds or minutes, reconnect to the server and make sure it is running: uptime
The system is now up to date, but before creating users and configuring security, you should put the server’s basic settings in order.
Configuring the time zone and server name
The correct time zone is required for logs, cron jobs, monitoring, and incident investigations. First, check the current settings: timedatectl
You can display the list of available time zones with the command: timedatectl list-timezones
After that, select the appropriate region, for example: sudo timedatectl set-timezone Europe/Berlin
UTC is also commonly used for server infrastructure: sudo timedatectl set-timezone UTC
It is best to replace the server name with a clear designation related to its role. For example: sudo hostnamectl set-hostname web-01
After making the change, you should verify the result:
hostnamectl
hostname
If the server will use a fully qualified domain name, you can set the FQDN: sudo hostnamectl set-hostname web-01.example.com
A clear name makes it easier to work with logs, monitoring, and multiple VPS instances. The time zone should be consistent across the entire infrastructure, or at least documented; otherwise, comparing events between servers becomes more difficult.
After the first login, updates, and basic system configuration, you can move on to the next step: creating a separate user, configuring an SSH key, and avoiding regular work as root.
Creating a Dedicated User and Securing SSH
User with sudo privileges
You should not work as root all the time: any mistaken command is executed without additional confirmation and with full access to the system. For day-to-day administration, it is better to create a separate user who elevates privileges only through sudo.
You can create a user with the command: adduser admin
You can use a different descriptive username instead of admin. The system will prompt you to set a password and offer to collect additional information; you can skip the optional fields.
Then the user must be added to the sudo group: usermod -aG sudo admin
If the command is not run as root, prepend sudo to it. You can check the new user’s groups as follows: groups admin
After that, you should open a separate SSH session and verify the login: ssh admin@SERVER_IP
Administrator privileges are checked with the command: sudo whoami
If everything is configured correctly, the command will return root. The user will continue working with standard privileges and will use sudo only for administrative tasks.
A separate account reduces the risk of accidental changes, but a password-based login can still be brute-forced or stolen. The next step is therefore to configure an SSH key.
Signing in with an SSH key instead of a password
An SSH key consists of a private and a public component. The private key remains on the user’s computer, while the public key is added to the server. When a connection is established, the server verifies that the private key matches an authorized public key without transmitting the account password.
If the key does not exist yet, it must be created on the local computer: ssh-keygen -t ed25519
By default, the files are saved in the .ssh directory in the user’s home directory. It is best to set an additional passphrase for the private key: it will protect the file if the computer or a backup ends up in someone else’s hands.
The easiest way to copy the public key to the server is with the command: ssh-copy-id admin@SERVER_IP
If you are using a Windows environment without ssh-copy-id, the contents of the file with the .pub extension can be manually added on the server to the file: ~/.ssh/authorized_keys
The directory and file must have the correct permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
After adding the key, open another terminal window and verify authentication: ssh admin@SERVER_IP
Do not disable password authentication until the new key-based login has been tested in a separate session. It is also best to keep the current connection open until setup is complete: it will allow you to fix the configuration if the new login stops working.
Only after a successful test should you disable the highest-risk remote access methods.
Disabling root login and password authentication
To strengthen security, you should disable direct root login, password-based authentication, and interactive password entry over SSH. On Ubuntu, OpenSSH settings may be stored not only in the main /etc/ssh/sshd_config file, but also in the /etc/ssh/sshd_config.d/ directory.
To avoid editing a large system file, you can create a separate configuration fragment: sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
Add the following parameters to the file:
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
After saving, check the configuration for errors: sudo sshd -t
If the command produces no output, the syntax is correct. After that, OpenSSH can be reloaded without fully restarting the server: sudo systemctl reload ssh
Do not close the old SSH session yet. First, connect again in a new window as a separate user: ssh admin@SERVER_IP
Next, make sure that sudo works and that the key is actually being used. Only after a successful check should you close the old root session.
If authentication stops working, return to the saved session, fix the configuration, run sudo sshd -t again, and reload the service.
After configuring a separate user and secure SSH access, administrative login becomes significantly safer. The next step is to restrict network access with a firewall, install Fail2ban, and check which ports the server exposes to the internet.
Firewall and Protection Against Password Brute-Force Attacks
Allow Only the Required Ports Through UFW
UFW is the standard interface for managing a host-based firewall in Ubuntu. It may be disabled by default, so before enabling it, you should first allow your current SSH access. Otherwise, you may lose the connection to the server after the firewall is enabled.
If SSH is running on the default port 22, you can allow it with the following command: sudo ufw allow OpenSSH
Alternatively, specify the port explicitly: sudo ufw allow 22/tcp
Next, set the baseline policies:
sudo ufw default deny incoming
sudo ufw default allow outgoing
You can now enable the firewall: sudo ufw enable
The following command allows you to check the status and active rules: sudo ufw status verbose
At the initial stage, you should open only the ports that are already in use:
- 22/tcp — SSH;
- 80/tcp — HTTP after the web server is installed;
- 443/tcp — HTTPS after the website is configured;
- other ports — only for specific services and when there is a clear need.
If SSH has been moved to another port, that specific port must be allowed before enabling UFW. You should not open port ranges or use an allow from any to any rule without a valid reason.
A firewall reduces the attack surface, but it does not analyze SSH login attempts. To temporarily block addresses that repeatedly fail authentication, you can use Fail2ban.
Installing and basic configuration of Fail2ban
Fail2ban analyzes service logs and temporarily blocks IP addresses after a series of failed login attempts. It complements SSH keys and a firewall, but does not replace them.
The package can be installed with the command: sudo apt install fail2ban -y
It is better to store local settings separately from the system jail.conf file so that a package update does not overwrite the changes. For SSH, you can create the following file: sudo nano /etc/fail2ban/jail.d/sshd.local
Add the following basic configuration to it:
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
If SSH is running on a non-standard port, a line with the required value is also added to the configuration, for example: port = 2222
After saving, enable and restart the service: sudo systemctl enable –now fail2ban
You can check the status of Fail2ban with the command: sudo fail2ban-client status
And check the SSH protection status like this: sudo fail2ban-client status sshd
Fail2ban is especially useful while password authentication remains enabled on the server. After switching to SSH keys only, the risk of brute-force attacks decreases, but the service can still filter out excess noise and suspicious activity.
After configuring the rules, it is important to check not only the UFW and Fail2ban configuration, but also which services are actually listening on network ports.
Checking Open Ports
An open port means that a service is accepting incoming connections. The more such services are accessible from the internet, the larger the attack surface.
You can view listening TCP and UDP ports with the following command: sudo ss -tulpen
For shorter output without process information, use: sudo ss -utln
When checking ports, it is useful to follow this outline:
| What was found | What to check |
| 22/tcp or another SSH port | Whether it matches the UFW rule |
| 80/tcp and 443/tcp | Whether a web server is installed and whether the ports should be accessible |
| 3306/tcp or 5432/tcp | Whether the database is exposed to the internet unnecessarily |
| Unknown port | Which process opened it and whether this service is needed |
| The service is listening on 127.0.0.1 | Accessible only locally, which is usually safer |
| The service is listening on 0.0.0.0 or :: | Accepts connections on all interfaces |
You can find out which process is using a specific port using the already executed ss -tulpen command, or separately, for example: sudo ss -ltnp ‘sport = :3000’
It is important to distinguish between a listening port and an allowing firewall rule. A service may listen on a port locally but be blocked from the outside by UFW. Conversely, an open UFW rule is not useful if the corresponding service is not running, but it may accidentally expose that service to the internet later.
After installing a new web server, database, control panel, or Docker, you should check the ports again. In a normal configuration, only the services that clients or administrators actually need to use should be accessible from the outside.
Once SSH is secured and unnecessary ports are closed, you can move on to automated updates and basic VPS health monitoring.
Automatic Updates and Basic Monitoring
Unattended Upgrades for Security Updates
Regular updates address known vulnerabilities in the operating system and installed packages. To ensure critical fixes do not depend on manual checks, you can enable automatic installation of security updates on Ubuntu.
First, install the required packages: sudo apt install unattended-upgrades apt-listchanges -y
Then enable automatic updates: sudo dpkg-reconfigure -plow unattended-upgrades
You can check the resulting settings in the following files:
/etc/apt/apt.conf.d/20auto-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades
In the default configuration, automatic installation usually applies to security updates. Regular application updates and upgrades between system versions are best performed in a controlled manner, especially on a production server.
The following command allows you to test the mechanism without actually installing packages: sudo unattended-upgrade –dry-run –debug
Logs are saved in the directory: /var/log/unattended-upgrades/
Automatic updates reduce the risk of missing an important fix, but they do not eliminate the need for monitoring. Some updates require restarting services or the entire VPS, and dependency changes can affect the application. Therefore, the server status should be checked regularly.
Monitoring CPU, RAM, disk usage, and availability
At the initial stage, you do not need to deploy a complex observability system. It is enough to monitor the basic VPS load, available disk space, running services, and server availability from the outside.
For manual checks, you can use the following commands:
| What to check | Command |
| System load and uptime | uptime |
| Processes and resource usage | top |
| RAM and swap | free -h |
| Free disk space | df -h |
| Directory size | du -sh /path/to/directory |
| Service status | systemctl –failed |
| Recent system errors | journalctl -p err -b |
| Listening ports | sudo ss -tulpen |
For a more convenient way to view processes, you can install htop: sudo apt install htop -y
After installation, it is launched with the command: htop
It is especially important to monitor free disk space. A full disk can stop the database, log writing, package updates, and backup creation even when CPU and RAM usage is low, and as a result can make SSH access impossible, requiring you to use the provider’s console if one is available.
At a minimum, monitoring should report at least the following events:
- The server has stopped responding;
- CPU usage remains high for an extended period;
- RAM is running out or swap is being used heavily;
- Disk usage has reached a critical level;
- An important service has stopped;
- The SSL certificate is about to expire.
It is better to check availability not only from the VPS itself, but also from an external service. A local command may show that the web server is running even though the site is unavailable from the internet because of a firewall, DNS, or network issue.
This completes the basic observability setup. However, monitoring only reports a failure; it does not restore deleted files or a corrupted database. Therefore, before deploying the site, you need to determine exactly what to back up, where to store the backups, and how to perform recovery.
Backups Before Installing the Website
What to back up
Backup planning should be done before the site is installed, not after the first failure. This ensures that files, databases, and configuration are included in a clear recovery plan from the start.
A backup typically includes:
- Site files and user uploads;
- MySQL, MariaDB, or PostgreSQL dumps;
- Web server configuration;
- Application settings and environment variables;
- Docker Compose configuration and related files;
- cron jobs and systemd units;
- A list of installed packages;
- Important firewall, SSH, and Fail2ban settings;
- Recovery instructions.
Secrets, keys, and passwords should be backed up with particular care. They should not be stored in plaintext alongside a regular site archive. For this type of data, it is better to use encrypted storage or a separate secrets manager.
For a dynamic project, copying only the site directory is not enough. If the database continues to change while the archive is being created, the files and data may represent different points in time. The database should therefore be saved as a separate, consistent dump.
After defining what the backup should include, you need to choose a storage location that will not disappear along with the VPS itself.
Where to store backups
A copy on the same server is convenient for quickly restoring individual files, but it does not protect against VPS deletion, disk failure, system compromise, or administrator error.
A minimal setup might look like this:
| Copy | Purpose |
| Local | Quick rollback of a file or configuration |
| External object storage | Protection against loss of the primary VPS |
| Provider snapshot | Fast recovery of the entire virtual machine |
| Additional long-term copy | Protection against an error or deletion discovered later |
For a small website, an automatic daily backup to external storage and retention of the last few versions is usually sufficient. For an online store, CRM, or application with an active database, more frequent backups may be required.
It is useful to follow a principle where data exists in at least several copies, and at least one copy is stored outside the primary site. The retention period is just as important as the backup frequency: if an error is discovered after a week, a single copy from yesterday will no longer help.
However, even external storage does not make a snapshot a full replacement for backups.
Why a snapshot is not a substitute for a full backup
A snapshot captures the state of a virtual machine or disk at a specific point in time. It is useful before an update, migration, or configuration change because it lets you quickly roll back the entire server.
However, a snapshot has limitations. It may be stored on the provider’s own infrastructure, be deleted together with the VPS, or fail to ensure consistency for an actively used database. In addition, restoring an individual file from a full snapshot is sometimes less convenient than restoring it from a standard archive.
A full backup differs in that it:
- Is stored separately from the primary server;
- Has a schedule and retention period;
- Allows individual files and databases to be restored;
- Can be encrypted;
- Is verified through a test restore;
- Does not depend on the existence of a specific virtual machine.
A snapshot is best used as an additional tool rather than the only layer of protection. For example, before a major update, you can create a snapshot while storing regular archives and database dumps in external storage.
After setting this up, you should perform at least one test restore. This is the only way to confirm that the archive opens, the database dump imports successfully, and the instructions actually make it possible to restore the project to a working state.
Once updates, access, the firewall, monitoring, and backups are configured, the first stage of VPS preparation can be considered complete. Next, we will consolidate all actions into a single checklist for the first hour after purchasing a server.
Checklist for the first hour after buying a VPS
Before installing your website, make sure the basic steps have been completed:
- The system has been updated and rebooted;
- The hostname and time zone have been configured;
- A separate user with sudo privileges has been created;
- SSH key-based login has been tested successfully;
- Root login and password authentication have been disabled;
- UFW is enabled, with only the required ports open;
- Fail2ban has been installed and is protecting SSH;
- Open ports have been checked with ss;
- Automatic security updates are enabled;
- Basic monitoring for CPU, RAM, disk usage, and availability has been configured;
- Backups are stored outside the primary VPS;
- A test restore has been performed at least once.
After that, you can install a web server, database, Docker, control panel, and the application itself.
If any of these items have been skipped, it is best to address that gap first. This is especially important for SSH access, the firewall, and backups: mistakes in these areas are the most common reason why the first failure or server compromise becomes harder to handle.
Common Mistakes During Initial Setup
Working as root
Working as root all the time increases the impact of any mistake. An incorrect path, accidental file deletion, or erroneous command can immediately affect the entire system.
For day-to-day tasks, it is better to use a separate user account and elevate privileges with sudo only when it is actually required. This makes administrative actions more visible and reduces the risk of accidental system changes.
However, a separate user account provides little protection if it is still secured only by a password.
Leaving password-based SSH login enabled
Password-based SSH is regularly targeted by automated brute-force attacks. Even a strong password can be stolen, reused, or accidentally exposed.
After verifying that SSH key authentication works, it is best to disable password authentication. However, do not close the current session until you have tested access again: an error in the key or configuration can result in losing access to the VPS.
An SSH key secures login, while a firewall limits which services are accessible from outside. Therefore, the next mistake is opening more ports than the project requires.
Opening all ports
A rule that allows all inbound traffic effectively defeats the purpose of a firewall. A database, admin panel, test service, or application running on an internal port may accidentally be exposed to the internet.
Only the required ports should be externally accessible: SSH, HTTP, HTTPS, and specific services with a clearly defined purpose. Databases and internal components should be bound to a local interface or a private network.
Even a minimal network attack surface will not protect a server if known vulnerabilities remain on it.
Failing to Update the System
A VPS image may already contain outdated packages when it is first launched. By postponing updates, the owner leaves vulnerabilities exposed even though fixes have already been released.
The system should be updated before the website is installed, and automatic security updates should then be enabled. At the same time, major updates to the application and its dependencies are best performed in a controlled manner, with a backup and the ability to roll back.
However, even an updated and secured server still does not guarantee that data will be preserved after an error or failure.
Installing the website before configuring backups
If the website is deployed before backups are configured, the initial data, settings, and changes remain unprotected. The problem may only become apparent after a failed update, file deletion, or database corruption.
Before launching a production project, you need to define what the backup will include, where it will be stored externally, how often copies will be created, and how long versions will be retained. After that, you should perform at least one test restore.
A proper initial VPS setup is performed in reverse order: first updates, access, firewall, monitoring, and backups, then the web server, database, and application. This approach takes slightly more time at the start, but it significantly simplifies ongoing operations and recovery after an incident.
Conclusion
Initial VPS setup does not require complex infrastructure, but the order of operations matters. First, update the server, create a separate user, verify SSH key-based access, and only then disable root login and password authentication.
The next layer of protection is a firewall, Fail2ban, and a review of open ports. These help reduce the attack surface and determine which services are actually accessible from the internet. Automatic security updates and basic monitoring help ensure you do not miss a vulnerability, overload, or low disk space.
Before installing the website, you should also configure external backups and test recovery. A provider snapshot can speed up a full VPS rollback, but it does not replace independent copies of files, configuration, and databases.
As a result, the first hour after purchasing a server is better spent building a secure foundation rather than installing the application. After that, further deployment becomes more predictable, and the impact of errors and failures is significantly reduced.
FAQ
Should you change the default SSH port?
Not necessarily. Moving SSH from port 22 reduces the number of automated login attempts and noise in the logs, but it does not provide strong protection on its own.
It is far more important to use SSH keys, disable password authentication and root login, configure UFW, and keep the system updated. If you do change the port, add the new firewall rule before restarting SSH.
Is UFW sufficient to secure a VPS?
No. UFW controls network access, but it does not eliminate application vulnerabilities or protect against every type of attack.
It should be used together with updates, a secure SSH configuration, user privilege restrictions, monitoring, and backups. For a public website, HTTPS, rate limiting, a WAF, and DDoS protection may also be required.
Is Fail2ban required when using SSH key authentication?
No, but it remains a useful additional layer of protection. After password authentication is disabled, brute-forcing a password over SSH is no longer possible, so Fail2ban’s practical role is reduced.
At the same time, the service can block repeated suspicious connection attempts and reduce the number of log entries. It should be used as a supplement to SSH keys and a firewall, not as a replacement for them.
Should automatic updates be enabled?
It is generally advisable to enable automatic installation of security updates. This reduces the risk of leaving a known vulnerability on the server because a manual update was missed.
However, the server still needs to be monitored. Some changes require services or the VPS to be restarted, and major updates to applications and third-party repositories are best performed manually after creating a backup.
When can the website be deployed?
After the system has been updated, a dedicated user has been created, SSH key login has been verified, insecure authentication methods have been disabled, and the firewall has been enabled.
It is also advisable to configure automatic updates, monitoring, and external backups in advance. If backups are planned for “after launch,” the project’s initial files and data will remain unprotected for some time.
Sources
1. Ubuntu Server Documentation — Firewall
2. Ubuntu Security Documentation — Security updates
3. Ubuntu Security Documentation — Firewall
4. Ubuntu Manpages — OpenSSH daemon configuration file
5. Fail2ban — Official repository and configuration examples
