title: Setup a Virtual Private Server (VPS)
excerpt: I have been avoiding getting an own server for quite a bit now. The setup and maintenance effort always kept me from getting one, but I recently crossed a threshold because any analytics solution that holds up to my standards would cost me the same as getting an Virtual Private Server (VPS) with probably enough resources to run quite some other stuff I already thought about several times.
coverImage: /assets/blog/setup-a-virtual-private-server-vps/cover.jpg coverImageInfo: Self created
date: "2023-06-16T6:00Z"
source: https://adriankast.notion.site/Setup-a-Virtual-Private-Server-VPS-116d0db0456f400e9eed05f54a8b1f00
I have been avoiding getting an own server for quite a bit now. The setup and maintenance effort always kept me from getting one, but I recently crossed a threshold because any analytics solution that holds up to my standards would cost me the same as getting an Virtual Private Server (VPS) with probably enough resources to run quite some other stuff I already thought about several times.
In addition I got the luck to have learned at least the basics about Linux administration at work and had a friend of mine that is a Linux admin providing me with basic instructions how to setup and secure a server. The following list is not complete for sure but will hopefully provide you with some practical guidance if you also have a server or you think about getting one.
There are many hosting provider that offer VPSs, often they are referred to as “V-Servers”. I decided to stick with Strato, since my Webspace is already hosted there, which simplifies GDPR concerns for me because I don’t have to adapt my privacy declaration or make a new ADV contract. At Strato the VPS costs me 6€ monthly for 4 virtual Cores, 8 GB memory and 300 GB SSD storage that is not the cheapest you will find but also not that expensive. Besides the price/resource ratio you should also look for limitations of the provided VPS especially since they are always virtualized there might be some. I’m quite ZUFRIEDEN with the Strato server so far, only exception is that I could not get docker to work properly with Ubuntu-22 (the port mapping never worked - not even to localhost, at least not without me deleting most of Iptables), which could have to do with their virtualization provider, docker and the Ubuntu distro. But since Debian is probably the better choice for a server anyway (less preinstalled stuff → less vulnerabilities) I’m not too sad about it. Once I had ordered the VPS I could select an OS to install (can be changed later as mentioned), provide a root user password (for VNC access) and public key (for SSH access) and the hosting provider took care of spinning the OS up. The following commands are specifically tested with Debian (and Ubuntu also mostly), but should work at least with every Debian-based Linux.
Use the following commands to create a non root user, add an SSH key for the user and disable SSH access directly to root. That ensures that nobody even if he gets in possession of your private SSH key has root access to your server. Also processes that do not required root rights can be executed without root access now. To be still able to executed root commands, we add the user to the sudoers group and make sure the user access is password protected.
adduser <username>
usermod -aG sudo <username>
su - <username>
sudo mkdir -p ~/.ssh
sudo touch .ssh/authorized_keys
sudo vim .ssh/authorized_keys
# paste the public key (i, ctrl+v, esc, :wq)
sudo chmod -R go= ~/.ssh
sudo chown -R <username>:<username> ~/.ssh
exit
exit
ssh -i .ssh/name_of_private_key_file <username>@<hostname>
# opt: disable password auth via ssh
sudo nano /etc/ssh/sshd_config
## set the following entries then save (ctrl o, enter, ctrl x):
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
# If you want to disable ssh access with root directly, also set the following entry to no
PermitRootLogin no
##
sudo systemctl restart ssh
The access via SSH key is very secure by default, but to protect your server from broot-force attacks or upcoming vulnerabilities even better you can easily change the port that is used for SSH connections. Also make sure that SSH access via password is disabled as shown in the preceding section.
sudo nano /etc/ssh/sshd_config
## set the following entry to your custom port (e.g. 122) then save (ctrl o, enter, ctrl x):
Port 122
##
sudo systemctl restart ssh
You can use the command sudo netstat -tulpn to see which ports are currently open on your OS. Then figure out which ones are not required (e.g. remote clock sync and dynamic IP assignment might be a good idea to keep) and keep them closed with UFW as shown in the section. If you just want to get ports listed that are listening sudo netstat -tulpn | grep LISTEN.