First steps: a server

Hi there

I have decided to try and make my IT setups more independent from US tech.

This is not of any ill will towards the many great US collegues that I have, but mostly as an exercise, since this seems like a troublesome task in general, and I want some kind of estimate of the trouble european companies are in if they decide they need to switch on a larger scale. This means that I have set some “guidelines” up for myself, to try and limit my exposement towards the US, both regarding payment, and regarding datastorage.

I am gonna be roleplaying a bit as a small company not entirely in the IT space, but with a small group of IT people, who will be able to do most tasks, but not do any large implementations by themself. I will occassionaly stray into my hobbies as I want to use this as an opportunity to host some hobby stuff as well.

Without further ado, this is gonna be my wishlist for this project (until it changes):

Minimal exposure towards US for data storage
Minimal exposure towards US for payment of services
Will priotize being feasible to migrate data from existing services
Will prioritize self-hosted solutions where easily available (which can probably extend to easy SAAS solutions available for a quick implementation, if a tech exit needs to get underway)
Will not allow closed-source self-hosted solutions. It is either open source, or it is a non-US company.

Since it seems like a good exercise to try and document my findings, the first steps should definitely be a blogging platform. I have chosen wordpress, as this is easy to set up, easy to use, and probably a well known problem for many anyway. This will make the first step really easy, which is nice.

First beginnings: A server

Well, where do you host stuff these days? Surely you can still just start a server in the basement, but with the additional headaches of being responsible for all maintenance, that is potentially gonna be a troublesome job (not in general, but if something goes wrong). Therefore, we will look towards someone who can handle the hosting for us.

Azure, AWS and Google cloud are obviously out of the picture, despite their impressive catalogue of services. This is the whole point to exit the US based tech. Since we’re looking to self-host as much as possible, we’re not looking for just a wordpress host, even though there are actually a good number of them available.

We decide to host a server on our own (here is a list of examples), and manage it ourselves – except the hardware maintenance, the cooling, the fallback internet connections and such. We justify this risk with the ability to backup our services and data, we can reestablish operations quite quickly, especially if we remember to script the setup of our services properly.

I have chosen to go with Hetzner, as they have this really nice “Server Auctions” going on, and our fictious company imagines that it will need a somewhat beefy server, with all the stuff we will move over to it. At least until we decide to split it up into microhosting again. (Hetzner also offers Virtual Private Servers, which is much more feasible for hobby and small-scale projects, but our IT team is ambitious!)

After ordering and recieving ther server, Hetzner offers to install Ubuntu on it easily, and we go with that.

Next up: Securing our domain

(Disclaimer: I am no linux wiz, and thus, I cannot roleplay my way out of being suddenly good at this stuff. I make do with what I already heard a bit about, some research, and trial and error)

With a new linux server, first we need to make sure it does not easily get broken into. This is of course always a risk when hosting your own stuff, but most places advocate for some standard practices, and we are going to follow suit.

Hetzner sends the login info in an email, so we now have root ssh access to the server. We need to get that locked down, changed the password and created something that is not root for accessing the server.

First login will look something like this in a terminal (or powershell)

ssh root@1.2.3.4

And then enter the password

Adding a new user

First we create a new user, which will be our primary admin, check that the user has been created, and add the user to the admin group

adduser newuser #Add a new user
cat /etc/passwd | grep newuser #Check that new user is present
usermod -aG sudo newuser #Add the new user to the sudo group

Enabling automatic updates

We update the package repository and upgrade installed packages by default. We also want to enable automatic updates, at least for security updates

apt-get update #Update list of packages
fapt-get upgrade #Upgrade installed packages

For ensuring automatic updates, the package “unattended-upgrades” seems to fit the bill, so we install this

apt-get install unattended-upgrades

The we can edit “/etc/apt/apt.conf.d/50unattended-upgrades” to make sure that the line with "${distro_id}:${distro_codename}-security"; is uncommented. It was by default for me.

Using certificates instead of passwords

This is more of a one-two punch. For one, it reduces the risk of revealing your password, as private keys are not something you go around remembering (not that you necessarily should remember your passwords, it is usually a good idea to have them randomised, and remembered for you), but additionally, it allows you to configure standard access to the server fro your machine without passwords. You still need your admin password for admin tasks, but you will not have to type it just to connect, and the split should also increase security, as neither can be useful without the other (at least for very malicious purposes)

It can seem a daunting task, but it is not that complicated when you get around to it.

Generate a key-pair

You can do this all over. You can use the built in openrsa in Ubuntu, you can do it in the browser, or you can do it on your own computer. I’m pretty sure you can do it in Windows easily as well. Some password stores also offer this feature.

The point is to generate a private/public key-pair, where one key is put on the server (in a liste of “trusted public keys”), and then we can use the private key (which noone has access to but us, even if they get ahold of the files on the server) to authenticate.

The key should consist of two files, which can be saved as text files, that look like this for the public key

and like this for the private key

(these are not my actual keys, they were just generated using the link above for this post)

Save the key as recognized

First things first, is to make room for the files we want to use, and to limit their access. We create the .ssh subdir in the user folder, and create the file authorized_keys in that, to contain our keys.

su - newuser #Switch to our new user
mkdir ~/.ssh
chmod 700 .ssh #Only allow this user access
touch authorized_keys #Generate the file to contain the keys
chmod 600 authorized_keys #Restrict access to only this user

Now we can add the public part of the key to the authorized_keys file. Just paste it in and save (I used nano, which some linux people will probably not really like, but it is easy, you open it with nano authorized_keys, paste the content, press control+S to save, and control+X to quit again.)

For the following part, it can be useful to switch back to the root user. If you just type exit, it should go back, but otherwise, you can always start an interactive sudo session with sudo -i

Next we need to enable the feature to log in like this, by editing the file /etc/ssh/sshd_config, where we need to make sure that the following values are set (scroll around a bit to find the ones with inversed values, and replace them. Uncomment if needed)

PasswordAuthentication no
PubkeyAuthentication yes

Finally, we need to restart the SSH service, for the changes to take effect.

service ssh reload

Using this, we can open a new terminal (or powershell on windows) to try and connect to the server. Keep the other terminal open, to make sure that we don’t loose access if something goes wrong.

ssh -i /path/to/privatekey newuser@1.2.3.4

If this connects, you can edit the /etc/ssh/sshd_config file for some more changes. We would like to block root access over ssh in general, and we would like to use another port (the standard is port 22, which is scanned by all sorts of auto-attack software). I got a random port from here. Edit the file and change the following values

PermitRootLogin no
Port 12345 #A random port will do

Once again, restart the ssh service

service ssh reload

Reboot the server using sudo reboot (you can omit the sudo, if you’re still in a root instance), and connect using the new port.

ssh -i /path/to/privatekey newuser@1.2.3.4 -p 12345

Making it easy again for ourselves

In order to not have to write out the whole path for the privatekey, user and ip each time we want to log in to the server, we can configure our ssh agent to use all of these by default. Create a new file called config under the .ssh folder in your userfolder (yes, even on windows!), and put the following values into it

Host dev
  HostName 1.2.3.4
  User newuser
  IdentityFile ~/.ssh/path/to/privatekey.key
  Port 12345

(also, change the private key path to match the actual path)

Now you can just start your terminal/powershell (restart, at least in powershells case) and type ssh dev, and you will connect. Remember your password though, as you will need it whenever you use sudo to elevate your privileges.

This is probably where I will stop for the first steps, but it should be enough for the server to exist for us to use again tomorrow.