VPS Setup Guide for Wienchain Masternodes
Setting up a Masternode requires a basic understanding of Linux and blockchain technology, as well as an ability to follow instructions closely. It also requires regular maintenance and careful security. There are some decisions to be made along the way, and optional extra steps to take for increased security.
Set up your VPS
A VPS, more commonly known as a cloud server, is a fully functional installation of an operating system (usually Linux) operating within a virtual machine. The virtual machine allows the VPS provider to run multiple systems on one physical server, making it more efficient and much cheaper than having a single operating system running on the “bare metal” of each server.
A VPS is ideal for hosting a Masternode because they typically offer guaranteed uptime, redundancy in the case of hardware failure and a static IP address that is required to ensure you remain in the Masternode payment queue. While running a Masternode from home on a desktop computer is technically possible, it will most likely not work reliably because most ISPs allocate dynamic IP addresses to home users.
We will use Vultr hosting as an example of a VPS, although DigitalOcean, Amazon EC2, Google Cloud, Choopa and OVH are also popular choices. First create an account and add credit. Then go to the Servers menu item on the left and click + to add a new server. Select a location for your new server on the following screen:
Vultr server location selection screen
Select Ubuntu 18.04 x64 as the server type. We use this LTS release of Ubuntu instead of the latest version because LTS releases are supported with security updates for 5 years, instead of the usual 9 months.
Vultr server type selection screen
Select a server size offering at least 2GB of memory.
Vultr server size selection screen
Enter a hostname and label for your server. In this example, we will use mn1 as the hostname.
Vultr server hostname & label selection screen
Vultr will now install your server. This process may take a few minutes.
Vultr server installation screen
Click Manage when the installation is complete and take note of the IP address, username and password.
Vultr server management screen
Set up your operating system
We will begin by connecting to your newly provisioned server. On Windows, we will first download an app called PuTTY to connect to the server. Go to the PuTTY download page and select the appropriate MSI installer for your system. On Mac or Linux you can ssh directly from the terminal — simply type ssh root@<server_ip> and enter your password when prompted.
PuTTY download page
Double-click the downloaded file to install PuTTY, then run the app from your Start menu. Enter the IP address of the server in the Host Name field and click Open. You may see a certificate warning, since this is the first time you are connecting to this server. You can safely click Yes to trust this server in the future.
PuTTY security alert when connecting to a new server
You are now connected to your server and should see a terminal window. Begin by logging in to your server with the user root and password supplied by your hosting provider.
Password challenge when connecting to your VPS for the first time
You should immediately change the root password and store it in a safe place for security. You can copy and paste any of the following commands by selecting them in your browser, pressing Ctrl + C, then switching to the PuTTY window and right-clicking in the window. The text will paste at the current cursor location:
Enter and confirm a new password (preferably long and randomly generated). Next we will create a new user with the following command, replacing <username> with a username of your choice:
You will be prompted for a password. Enter and confirm using a new password (different to your root password) and store it in a safe place. You will also see prompts for user information, but this can be left blank. Once the user has been created, we will add them to the sudo group so they can perform commands as root:
usermod -aG sudo <username>
Now, while still as root, we will update the system from the Ubuntu package repository:
The system will show a list of upgradable packages. Press Y and Enter to install the packages. We will now install a firewall (and some other packages we will use later), add swap memory and reboot the server to apply any necessary kernel updates, and then login to our newly secured environment as the new user:
apt install ufw python virtualenv git unzip pv
(press Y and Enter to confirm)
ufw allow ssh/tcp
ufw limit ssh/tcp
ufw allow 8888/tcp
ufw logging on
(press Y and Enter to confirm)
fallocate -l 4G /swapfile
chmod 600 /swapfile
Add the following line at the end of the file (press tab to separate each word/number), then press Ctrl + X to close the editor, then Y and Enter save the file.
/swapfile none swap sw 0 0
Finally, in order to prevent brute force password hacking attacks, we will install fail2ban and disable root login over ssh. These steps are optional, but highly recommended. Start with fail2ban:
apt install fail2ban
Create a new configuration file:
And paste in the following configuration:
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
Then press Ctrl + X to close the editor, then Y and Enter save the file. Restart and enable the fail2ban service:
systemctl restart fail2ban
systemctl enable fail2ban
Next, open the SSH configuration file to disable root login over SSH:
Locate the line that reads PermitRootLogin yes and set it to PermitRootLogin no. Directly below this, add a line which reads AllowUsers <username>, replacing <username> with the username you selected above. Then press Ctrl + X to close the editor, then Y and Enter save the file.
Then reboot the server:
PuTTY will disconnect when the server reboots.
While this setup includes basic steps to protect your server against attacks, much more can be done. In particular, authenticating with a public key instead of a username/password combination and enabling automatic security updates is advisable. More tips are available here. However, since the Masternode does not actually store the keys, these steps are considered beyond the scope of this guide.