First 15 Minutes on a New VPS: Server Setup and Security

A new server on the internet starts getting password-brute-forced within minutes of appearing. This is not an exaggeration: bots scan address ranges around the clock, and port 22 with the root login is the most common target. What follows takes fifteen minutes and eliminates almost all mass-scale risk.

Commands are given for Ubuntu and Debian. Execute them in order without closing the current SSH session — this is important, and I will explain why below.

If you do not have a server yet

Deployment takes about a minute. In the NodexGo panel, click Create Server, choose a location — your real ping to each one is shown next to it — then select a plan and system image, set a name, and confirm the order. On the last step you can pay for 1, 3, 6, or 12 months upfront.

The IP address and root password will appear in the panel and be sent to your email. Then follow the commands below.

1. Update the system

apt update && apt upgrade -y

A freshly installed image is almost always a few weeks behind, and among those updates there are often security patches. This is the first thing to do on any new machine.

2. Create a user instead of root

Working under root all the time is a bad habit: any typo executes without question and with full privileges.

adduser deploy
usermod -aG sudo deploy

Replace deploy with any name you like. Set a long password — it will be needed for sudo.

3. Set up key-based login

On your own computer, if you do not have a key yet:

ssh-keygen -t ed25519

Copy it to the server:

ssh-copy-id deploy@your-ip

Now open a SECOND terminal window and verify that key-based login works. Do not close the first session — if something is configured incorrectly, it will remain the only way to get back into the server.

ssh deploy@your-ip

Even if you do lock yourself out — it is not fatal: in the NodexGo panel every server has a VNC web console that works independently of SSH and the network. You can use it to log in and fix the configuration.

4. Disable password login and root login

Only after key-based login has been verified. Open /etc/ssh/sshd_config and set these three lines as follows:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Restart the service:

systemctl restart ssh

From this point on, password brute-forcing is useless: there simply is no password. This is the single most effective measure on the entire list.

5. Enable the firewall

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

The SSH rule is added first — otherwise enabling the firewall will cut you off from the server. Only open the ports you actually need: a database should almost never be exposed to the outside world.

6. Install fail2ban

apt install fail2ban -y

It reads logs and temporarily blocks addresses from which failed login attempts originate. With password authentication disabled this is already a second line of defense, but it reduces noise and protects other services such as mail.

7. Add swap if memory is limited

On a server with 1 to 2 GB of RAM, swap saves processes from sudden death during load spikes.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

To make swap persist after a reboot, add the following line to /etc/fstab:

/swapfile none swap sw 0 0

8. Small things you will regret skipping

Timezone — otherwise all logs will be in UTC and investigating an incident will turn into arithmetic:

timedatectl set-timezone Europe/Moscow

Automatic security updates. For a server that no one monitors daily, this is a reasonable compromise:

apt install unattended-upgrades -y

Server hostname — when you have more than one server, you will thank yourself later:

hostnamectl set-hostname web-1

What not to do

Do not change the SSH port from 22 to a non-standard one hoping for security. It removes noise from the logs but does not protect anything: a scanner finds an open port in seconds. Disabling password authentication protects you; changing the port does not.

Do not install a control panel just in case. Every panel is another web interface with root privileges that needs to be kept updated. Install one only if you genuinely need it.

What comes next

After these steps the server is ready to use: you can install a web server, deploy an application, or set up Docker. It is also worth configuring backups right away — on a VPS that responsibility is yours, and it is the only thing that saves you after a serious mistake.

If something goes wrong and the server is unreachable via SSH, its card in the panel has buttons for Reboot, Change root password, Reinstall OS, and a web console. Reinstalling brings back a clean system in a couple of minutes — at the experimentation stage that is a perfectly normal working tool.