How to set up your VPS

So you want to set up your own VPS and are looking for a quick guide to see how? That’s cool. I’ve actually created this post to remind myself of the steps I need to take each time I’m setting up a bare-bones VPS (not a cloud platform, like DigitalOcean).

Step 1: Establish Connection

In my case I always start off with a VPS, where I get an IP address that I can ssh into, usually with root credentials. To test connection and see if everything is well set up, do this:

ssh root@my-ip-or-domain.com

Hopefully you’ll be prompted for your root password, which you should enter to find yourself in a shell inside your VPS. At this point you can look around, do an apt-get update (or whatever package manager yours comes with) to see if everything’s fine.

Step 2: Create Account(s)

Now that you’re in the system, you want to create another user other than root, because you want some way to restrict access to the operating system on your VPS. The plan is to create a user that we use to access and operate on our system and leave root alone entirely. We’ll also introduce sudo to allow our new user to use some commands that are otherwise restricted. Of course this is easier to control this way.

In our example we’ll add the user named daniel.

To add a new user do:

useradd -m daniel

I also usually add the -U flag to also create a user group with the same name. This is great if I want to set this up for a new project and I may be adding new users soon to the same user group.

Next I’ll change the password for this new user:

passwd daniel

I answer the prompt with the new password: password123 - of course.

Step 3: Add Account to Sudoers

In the next step we add the previously created account to the sudoers group, which will give it right to do stuff it shouldn’t if the password is entered.

usermod -aG sudo daniel

We can test it worked by switching over to our new user with

su - daniel

and then trying to do something we should not with this account, like access /root. First confirm you really have no access to it, by entering:

ls -a /root

If this gives you permission denied warning, you’re on the right track, now try with sudo:

sudo ls -a /root

and surely enough you should be prompted for your password. Upon entering it, the terminal should come up with the contents of /root. To switch back to root at any point you can su - root or sudo su.

At this point you can log out and log back in via ssh using your new account, so in my case daniel@my-ip-or-domain.com.

Step 4: Set Up SSH Keys

Next thing I like to so is instead of having to type in my extremely long and difficult password of password123, I like to use a private and public key pair on my machines, of which the public version is added to the remote host (a.k.a.: my VPS) and so it knows my computer is most likely the real deal when trying to connect and it will happily let me in without having to type an actual password. You can think of this as Google’s Password storing solution but for ssh and everything that connects via ssh like git. So let’s set up an ssh key.

While being logged into your own machine, which you will be using in the future to access this remote one, type in the terminal:

ssh-keygen -t rsa

This will prompt you for some basic info, like where you want to store your keys, just press enter at all of them, we love defaults. In the last one it will ask if you want a password. I just said I hate passwords, so I press enter, however a serious user like you should probably set one up, you know… just in case. By the way you will be prompted for this password each time you try to use your public key, but worry not. You can use ssh-agent, which will take care of that for you automatically.

The important thing to know is that when you add this public key to your server, the machine that stores that key will be able to log in, unless a new key from a new computer is added, in which case those will be able to log in too. It’s always a good idea to have at least one user with password access that can create back-ups of your server’s valuable data, in case things go very wrong. This is also however a security risk. Do not worry, though, at this point we can still log in using our passwords. So let’s send to the server our public key, using a nice tool, called ssh-copy-id. The command is this:

ssh-copy-id daniel@my-ip-or-domain.com

This will take care of everything for you in the background and you should be able to log in, using your key instead of password. If you don’t believe me, test it out.

Step 5: Disallow root from Logging In

Next thing we can do is changing the configuration to stop root from loggin in altogether or logging in via SSH Keys only, however for that to work you should add a computer’s SSH Key that you trust will always be in your possession, as a backup basically. I tend to stop root from loggin in altogether.

Edit your /etc/ssh/sshd_config (or wherever the config file is stored) to include the line

PermitRootLogin no

Afterwards you can reload the SSH Deamon with:

sudo systemctl reload ssh

Other options for the setting are: without-password (instead of no) to allow root to only be logged in via SSH Keys or forced-commands-only when you want this user to only be able to send commands, but not get a shell. (This approach is used to send backups, like a shell script that calls pg-dump and then zips and sends it somewhere.)

Step 6: Extra Security

Real security is an illusion. If you want to operate your own VPS and are storing data that needs to be secure, hire a professional. If other people depend on the data you store and you don’t know how to be absolutely sure and secure then just don’t do it. Use a cloud platform or ask someone who’s really good at this stuff (not me).

As extra security, you can add fail2ban, with a simple

sudo apt-get install fail2ban

you get out-of-the-box protection against some brute-force attacks against your SSH server.

I also like to set up strong firewall rules, which I will definately not outline here. It’s way too long and complicated. There are books on this stuff. Anyways I recommend reading up on iptables and at least setting up some basic rules, like allowing TCP/IP on ports 80 and 443, SSH acces on port 22, or whichever port you’re using… To find that out do:

cat /etc/ssh/sshd_config | grep Port

I usually block everything else and use a reverse proxy to access services running on other ports.

Conclusion

I hope that list helps you. I recommend reading up more on security as it’s very important and you can’t care enough about it.

Otherwise happy coding!