{"id":61407,"date":"2021-03-26T08:31:15","date_gmt":"2021-03-26T14:31:15","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=61407"},"modified":"2025-11-21T14:28:16","modified_gmt":"2025-11-21T20:28:16","slug":"6-easy-steps-to-configure-your-first-vps-server","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/6-easy-steps-to-configure-your-first-vps-server\/","title":{"rendered":"How to Configure Your First VPS Server in 6 Steps (Beginner’s Guide 2025)"},"content":{"rendered":"\n
Not sure how to configure your new VPS? You’ve come to the right place.<\/p>\n\n\n\n
This step-by-step guide has helped thousands of website owners get their virtual servers up and running, and now, it’s going to help you as well. Even if you’ve never managed a virtual server before, you can follow the instructions and get your project underway in less than an hour<\/strong>.<\/p>\n\n\n\n
We haven’t got much time to lose, so without further ado, let’s take a closer look at the steps.<\/p>\n\n\n\n
1. Access the Server via SSH<\/h2>\n\n\n\n<\/figure>\n\n\n\n
A typical VPS supports many communication protocols, but the one you need to use in this case is SSH.<\/p>\n\n\n\n
SSH stands for Secure Shell<\/strong>, and it’s designed to allow you to execute commands remotely<\/strong>. It uses encryption <\/strong>to protect the communication between your home computer and your virtual server and ensure no one can see the information being exchanged.<\/p>\n\n\n\n
Establishing an SSH connection is pretty straightforward.<\/p>\n\n\n\n
If your home computer uses a Unix-based operating system <\/strong>like Linux or macOS, you can use the Terminal<\/strong>. On a Windows machine, you can open a shell with either PowerShell or the Command Prompt (cmd.exe)<\/strong>.<\/p>\n\n\n\n
The built-in tools do the job, but many people still prefer to use dedicated SSH client applications like PuTTY <\/strong>because of their convenient features. These apps can save sessions, store keys, and remember credentials for you, saving you a lot of time when connecting to your server.<\/p>\n\n\n\n
Accessing the VPS via SSH for the first time requires the login credentials provided by your host. In the command line, you need to enter:<\/p>\n\n\n\n
ssh [username]@[server IP]<\/em><\/p>\n\n\n\n
The server will receive the request via port 22<\/strong>, identify the username<\/strong> (if you’re logging in with the root user, it’s “root”), and ask for your password<\/strong>. After you provide the correct details, the server will display a welcome message in the command-line interface.<\/p>\n\n\n\n
With that, you have logged into your new VPS for the first time.<\/p>\n\n\n\n
2. Update the Server<\/h2>\n\n\n\n<\/figure>\n\n\n\n
Keeping the software on your VPS up-to-date is a significant part of ensuring it’s fast, reliable, and secure. Updates include security patches <\/strong>for various vulnerabilities that occasionally crop up, as well as new features and performance enhancements. After your first login, it’s a good idea to ensure all the latest versions are installed.<\/p>\n\n\n\n
Different distributions use different package managers – the tools used for installing and managing software in Linux. Debian-based distributions like Ubuntu are usually equipped with APT<\/strong>, whereas most Red Hat-based systems like Rocky Linux and Fedora use DNF<\/strong>.<\/p>\n\n\n\n
Some legacy Red Hat-based distros still use the YUM <\/strong>package manager, in which case, you’ll need to replace dnf<\/em> in the commands below with yum<\/em>. That said, you’re unlikely to be using an operating system this old.<\/p>\n\n\n\n
The update process starts with refreshing the package lists and identifying new versions of the installed software. For Ubuntu<\/strong> and other Debian-based<\/strong> distributions, for example, you’ll use:<\/p>\n\n\n\n
$ apt update<\/em><\/p>\n\n\n\n
For Red Hat-based distributions<\/strong>, the command is:<\/p>\n\n\n\n
$ dnf check-update<\/em><\/p>\n\n\n\n
Next, you tell the server to install the updates<\/strong>.<\/p>\n\n\n\n
For Debian-based distributions, the command is:<\/p>\n\n\n\n
$ apt upgrade<\/em><\/p>\n\n\n\n
In Red Hat-based distributions, you need to use:<\/p>\n\n\n\n
$ dnf update<\/em><\/p>\n\n\n\n
The process may take a while. After the update, it’s a good idea to restart the server using the reboot<\/em><\/strong> <\/em>command.<\/p>\n\n\n\n
3. Set up a Firewall<\/h2>\n\n\n\n<\/figure>\n\n\n\n
A firewall is a basic security feature present on almost any server. However, this doesn’t make it any less important.<\/p>\n\n\n\n
The firewall controls your VPS networking ports and decides what traffic passes through them. It filters incoming requests and ensures data integrity<\/strong>.<\/p>\n\n\n\n
You’d think that setting up a firewall yourself is tricky, but fortunately, this isn’t the case. Before we get to the actual steps, however, let’s take a closer look at the tools you will be using.<\/p>\n\n\n\n
The Linux ecosystem has produced several firewall solutions over the years, but the one that has fared the best is iptables<\/em>. Because it has withstood the test of time so well, either iptables or its successor, nftables<\/em>, is built into almost every Linux system nowadays.<\/p>\n\n\n\n
It’s a packet filtering<\/strong> and Network Address Translation<\/strong> system that works with the Netfilter framework to give you complete control over all traffic on your server. As their names suggest, iptables and nftables use tables<\/strong>. The tables contain chains<\/strong>, which, in turn, contain rules<\/strong>.<\/p>\n\n\n\n
The difference between the two is in the syntax.<\/p>\n\n\n\n
The use of tables, chains, and rules makes your firewall incredibly powerful, but the downside is that it’s not exactly straightforward to work with out of the box. Fortunately, there are a couple of firewall management applications that can make your life a whole lot easier. You’ll want to use them when setting up your virtual server.<\/p>\n\n\n\n
\n
UFW<\/strong><\/li>\n<\/ul>\n\n\n\n
UFW stands for Uncomplicated Firewall<\/strong>, a user-friendly command-line utility that lets you control iptables’s rulesets with fewer commands and a more intuitive syntax. Although it can be used on Red Hat-derived operating systems, UFW is pre-installed and primarily aimed at Debian-based systems<\/strong>.<\/p>\n\n\n\n
If you don’t have it on your Debian server, you can easily install it with the following command:<\/p>\n\n\n\n
$ apt install ufw<\/em> <\/p>\n\n\n\n
If you’re not using the root account, you’ll need to add the sudo <\/em>prefix to the front. It’s a good idea to remove any other firewall management tools<\/strong>. Otherwise, you risk hitting conflicts and potential stability issues.<\/p>\n\n\n\n
Another recommended step is to reset all UFW rules with the following:<\/p>\n\n\n\n
$ ufw reset<\/em><\/p>\n\n\n\n
At this point, it’s essential to enable SSH immediately, or you risk locking yourself out. The command is:<\/p>\n\n\n\n
$ ufw allow OpenSSH<\/em><\/p>\n\n\n\n
The next port of call is to set the default policy. The recommended settings block all incoming and allow all outgoing traffic. The commands are:<\/p>\n\n\n\n
Blocking any incoming traffic is recommended as a security baseline. However, if you leave the settings in this state, your website won’t be accessible to the outside world. To ensure it is, you need to enable HTTP and HTTPS connections:<\/p>\n\n\n\n
Some of you may notice that we’re not enabling FTP. That’s because SSH allows you to upload and manage files through a more secure SFTP <\/strong>connection. All you need to do is select the correct protocol in your FTP client when connecting to your server.<\/p>\n\n\n\n
With that, all essential services should be up and running. To double-check, run:<\/p>\n\n\n\n
$ ufw status<\/em><\/p>\n\n\n\n
Make sure everything looks good, and pay particular attention to SSH. If the protocol is disabled, you may get locked out. The changes take effect after you enable UFW.<\/p>\n\n\n\n
$ ufw enable<\/em><\/p>\n\n\n\n
\n
Firewalld<\/strong><\/li>\n<\/ul>\n\n\n\n
Many people believe that Firewalld is just UFW for Red Hat-based distributions, but this is not strictly the case.<\/p>\n\n\n\n
The two utilities have different syntaxes and differ slightly in how they handle rules. Firewalld introduces zones that allow for more flexible control over incoming traffic<\/strong>. You don’t need to restart the service every time you make changes to the configuration, which in turn means that it’s easier to find GUI-based management tools for it.<\/p>\n\n\n\n
Overall, Firewalld is a more advanced firewall management utility with a broader range of features and traffic filtering mechanisms. However, the steps to set it up and configure it are similar.<\/p>\n\n\n\n
Your first job is to install Firewalld if you don’t have it already. On Red Hat-based systems, you do it via:<\/p>\n\n\n\n
$ dnf install firewalld<\/em><\/p>\n\n\n\n
Next, you need to start the service and ensure it fires up at every boot:<\/p>\n\n\n\n
By default, Firewalld allows all outgoing traffic, so to set up a secure baseline, you just need to set the default policy to block incoming requests. You can do that using:<\/p>\n\n\n\n
Finally, reload the firewall to save all changes:<\/p>\n\n\n\n
$ firewall-cmd –reload<\/em><\/p>\n\n\n\n
NOTE: <\/strong>If you’re not using the root user, all commands listed above must be preceded by the sudo <\/em>prefix.<\/p>\n\n\n\n
4. Create a New User<\/h2>\n\n\n\n<\/figure>\n\n\n\n
Until now, we’ve assumed you’re using the server’s root<\/strong> user.<\/p>\n\n\n\n
The root user in Linux is the system’s owner. Its privileges are unlimited \u2013 as long as you’re logged in as root<\/strong>, you can do anything with the server.<\/p>\n\n\n\n
Any small mistake could have dire consequences because of the elevated privileges, so creating a second account with superuser permissions<\/strong> is generally considered good practice. With it, you can still configure your server’s most important settings. Still, you’ll need to add the sudo<\/strong> prefix<\/strong> to every command, and you’ll have quite a few more warnings and prompts when performing tasks that require administrative privileges.<\/p>\n\n\n\n
It may seem like a minor difference, but there are a few reasons why you should consider doing it:<\/p>\n\n\n\n
\n
The root account has completely unrestricted access<\/strong>. The wrong command could do irreparable damage, and there are no warnings to make you think twice.<\/li>\n\n\n\n
Using the root account will leave no audit trail<\/strong>. Debugging is more problematic, and finding out what happened if a security breach occurs will be difficult.<\/li>\n\n\n\n
Root accounts are often targeted by brute-force attacks<\/strong>. The reason is that the default username is always “root.”<\/li>\n\n\n\n
A second user account gives you better access control. You can apply the principle of least privilege and revoke access or restrict it to specific commands.<\/li>\n<\/ul>\n\n\n\n
After you’re logged in as root, you can create a new user account with:<\/p>\n\n\n\n
$ adduser [the new user’s username]<\/em><\/p>\n\n\n\n
If the server doesn’t automatically ask you to set a password for the new user, you can do it with:<\/p>\n\n\n\n
$ passwd [the new user’s username]<\/em><\/p>\n\n\n\n
Next, you need to assign the new user account to the admin group. There are variations in the way Linux distributions treat users. In Debian-based systems like Ubuntu, the default admin user group is sudo<\/em><\/strong>. In Red Hat-based distributions like CentOS and Rocky Linux, however, it’s called wheel<\/em><\/strong>.<\/p>\n\n\n\n
Hence, if you use a Debian-based server, you need to enter:<\/p>\n\n\n\n
$ usermod -aG sudo [the new user’s username]<\/em><\/p>\n\n\n\n
And if your VPS runs on a Red Hat-based distribution, you need:<\/p>\n\n\n\n
$ usermod -aG wheel [the new user’s username]<\/em><\/p>\n\n\n\n
With a couple of additional commands, you can confirm that the process has been successful.<\/p>\n\n\n\n
First, switch to the new account with the following:<\/p>\n\n\n\n
$ su – [the new user’s username]<\/em><\/p>\n\n\n\n
Then, check whether the new user has superuser privileges with:<\/p>\n\n\n\n
$ sudo whoami<\/em><\/p>\n\n\n\n
The output should read root<\/em><\/strong>.<\/p>\n\n\n\n
You now have an account with superuser privileges, so you can safely disable SSH access for the original root user<\/strong>. This reduces the attack surface during a brute-force campaign against your server and helps you prevent a security breach that could have serious consequences.<\/p>\n\n\n\n
First, ensure the root user is logged out (you can use the exit<\/em> command) and open a new SSH session using the account we just created.<\/p>\n\n\n\n
Disabling root SSH access means editing the primary SSH configuration file, so it’s a good idea to create a backup before you continue. Go to the root directory (the one denoted by a single forward slash \/) and enter the following:<\/p>\n\n\n\n
Now, you can open the sshd_config file and make the necessary changes. You can use any text editing utility you want. In our example, we chose Nano <\/strong>because it’s renowned as one of the most user-friendly utilities of its kind. The command is:<\/p>\n\n\n\n
After you provide your account’s password, Nano will open the SSH configuration file. Find the line that says:<\/p>\n\n\n\n
PermitRootLogin yes<\/em><\/strong><\/p>\n\n\n\n
and change it to<\/p>\n\n\n\n
PermitRootLogin no<\/em><\/strong><\/p>\n\n\n\n
If there is a #<\/em><\/strong> character at the beginning of the line, remove it. Press ctrl\/cmd + X<\/em><\/strong> to exit and save the changes when prompted. Finally, it’s time to restart the SSH service. <\/p>\n\n\n\n
$ sudo systemctl restart sshd<\/em><\/p>\n\n\n\n
In some cases, you might need to use ssh<\/em> instead of sshd<\/em>. With that, you have a new superuser account, and the root user is disabled.<\/p>\n\n\n\n
5. Change the Default SSH Port<\/h2>\n\n\n\n<\/figure>\n\n\n\n
Port 22<\/strong> is SSH’s default listening port<\/strong>. Users know that, and so do hackers.<\/p>\n\n\n\n
A strong password limits the risks to a certain extent, but it’s still better to ensure that the door the criminals are knocking on is locked.<\/p>\n\n\n\n
Yet again, we need to edit the primary SSH configuration file. If you don’t have a backup of it, create one now.<\/p>\n\n\n\n
After going back to the root directory, enter:<\/p>\n\n\n\n
If there is a #<\/strong> character at the beginning of the line, remove it and replace 22<\/strong> with any number<\/strong> between 1024 and 65535<\/strong>. Ports below 1024 are privileged and usually require root permissions, so it’s not a great idea to use them. The port you choose mustn’t be used by any other services<\/strong>.<\/p>\n\n\n\n
Your next job is to ensure your firewall accepts connections at that port.<\/p>\n\n\n\n
The exact command depends on your firewall management utility.<\/p>\n\n\n\n
For UFW, it’s:<\/p>\n\n\n\n
$ sudo ufw allow [the custom SSH port number]\/tcp<\/em><\/p>\n\n\n\n
Finally, restart the SSH service to ensure the changes take effect. The command is:<\/p>\n\n\n\n
$ sudo systemctl restart ssh<\/em><\/p>\n\n\n\n
for Debian-based distros and<\/p>\n\n\n\n
$ sudo systemctl restart sshd<\/em><\/p>\n\n\n\n
for Red Hat-based systems.<\/p>\n\n\n\n
Generate SSH Keys<\/h2>\n\n\n\n<\/figure>\n\n\n\n
Changing SSH’s default listening port protects your servers against automated scripts that scan the internet in an attempt to infiltrate random servers. However, to block targeted attacks<\/strong>, it’s best to beef up your authentication mechanism<\/strong> as well.<\/p>\n\n\n\n
The traditional username-and-password system can be efficient if you choose a strong enough password, but an SSH public-and-private key pair makes for a more secure setup. To use it, you first need to generate the said keys.<\/p>\n\n\n\n
In Windows, the easiest option is to use the PuTTYgen<\/strong> application bundled with the popular SSH client. After you open it and click Generate<\/strong>, it will use the random motions of the mouse cursor to create one public and one private key. You can also set a passphrase<\/strong> that works alongside the key pair for additional security.<\/p>\n\n\n\n
The private key remains on your computer, so you can click Save private key<\/strong> and decide where to store it. You’ll also need to upload the public one to your server, but before we get to that, let’s see how Linux and MacOS users generate their keys.<\/p>\n\n\n\n
Unix-based operating systems have a built-in utility called ssh-keygen<\/em>, which allows them to create key pairs without installing additional software.<\/p>\n\n\n\n
The command for creating a key pair looks like this:<\/p>\n\n\n\n
The Terminal will ask you to choose a file path for your private key. By default, it saves it in ~\/.ssh\/id_rsa<\/em>. <\/p>\n\n\n\n
Finally, it requests a passphrase, after which it saves your public and private keys in the same folder. The public key gets a .pub <\/em>extension, so if the private one is saved as ~\/.ssh\/id_rsa<\/em>, the public will be stored in ~\/.ssh\/id_rsa.pub<\/em>. You can open it with Nano and see the public key. Now, you need to copy it to your server.<\/p>\n\n\n\n
Open a new SSH session and go back to your user’s home directory. This is the folder you land in after you log in, but you can ensure you’re in the right place by entering:<\/p>\n\n\n\n
$ cd ~<\/em><\/p>\n\n\n\n
If you enter pwd <\/em>at this point, the output should be \/home\/[your account’s username]\/<\/em><\/strong>.<\/p>\n\n\n\n
Create a folder to host your public key and set the correct permissions for it:<\/p>\n\n\n\n
Copy the public key and paste it in Nano. Save the file and exit.<\/p>\n\n\n\n
On Linux and MacOS, you log in through the Terminal as usual.<\/p>\n\n\n\n
If you use Windows, open PuTTY, go to its settings, and click Connection<\/strong> > SSH<\/strong> > Auth<\/strong>. In the Private Key File for Authentication<\/strong> field, select your private key and save the changes.<\/p>\n\n\n\n
If you don’t use other devices to log into your server, you can disable your account’s password authentication.<\/p>\n\n\n\n
To do that, you need to edit the SSH configuration file \u2013 etc\/ssh\/sshd_config<\/em>. It’s as simple as changing the PasswordAuthentication<\/strong> value from Yes<\/strong> to No<\/strong>.<\/p>\n\n\n\n
![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-SSH-1140x300-1.webp\")
<\/figure>\n\n\n\n![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-UpToDate-1140x300-1.webp\")
<\/figure>\n\n\n\n![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-Firewall-1140x300-1.webp\")
<\/figure>\n\n\n\n![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-CreateUser-1140x300-1.webp\")
<\/figure>\n\n\n\n![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-ChangePort-1140x300-1.webp\")
<\/figure>\n\n\n\n![\"How](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2021\/03\/How-to-configure-your-first-VPS-Server-in-6-Steps-GenerateKey-1140x300-1.webp\")
<\/figure>\n\n\n\n