Every time you use a free web service like Google, DropBox, and Twitter, you are allowing personal data to be collected, analyzed, and monetized. Additionally, at least once a week it seems like, there’s a big data breach, leak, or hack that makes the news. Companies like Facebook, Google, Equifax, and even the IRS are allowing your data to be obtained by unauthorized third parties. Some of this data may surprise you. Companies like Google track where you are, what apps you’re using on your phone, the content of your emails, text messages, and other communications. Even if you delete your account, Facebook still tracks who you are, what your credit score and spending habits are, and more. Even if you think you are totally OK with this behavior, you have no way of actually verifying or auditing precisely what data they are collecting, and who they are sharing it with.
Presumably, you are reading this tutorial because you want to take back some control over your digital life. However, you likely don’t want to abandon the internet entirely. It’s useful, convenient, and fun. And there’s no reason you should allow bad behavior by big actors to push you off of an open space. If you’re going to engage with the internet, you and all your data will need a centralized home that makes it easy to track, store, and manage what information you would like to be connected. The best way to do this is to set up a single web server that you can run all of your services from. To do this, you have two options:
- Hook up a physical PC to your internet, and run server software on it.
- Rent a virtual private server from a 3rd party host.
Both of these options have advantages and disadvantages. The advantages for using your own PC are that it’s local, so you know that only you have access to it, it’s potentially cheaper if you have an old computer laying around, and your access speeds from home will be substantially faster if you set it up to be locally networked. The disadvantages, however, are numerous. Unless you have a business internet connection, you probably don’t have a business IP address, which means that you won’t be able to easily hook it up to a domain name. Your ISP may block hosting on their residential connections. Your upload speeds may be slow, which means it will serve files slowly. Additionally, being on your local network means you can’t use it to host a VPN to secure your web traffic from home. And you need to take care of it: set up disk redundancy so that if the hard drive dies, you don’t lose your data. If your power or internet goes down, so will your server.
It is for those reasons that I recommend getting your feet wet with a virtual private server. A virtual private server (VPS) is a virtual operating system hosted at a datacenter. You usually get your own private Linux installation that you can then use to run your server from, and they usually include a static IP address so you know you will always be able to access it. They can be had for as cheaply as $5/month, and many companies also offer automatic backups for $2-$5/month as well, in addition. While the downside is that your physical data is in the hands of another party, one important thing to remember is that as a paying customer, most companies have more respect for your data, and have clear and distinct policies regarding when it will be accessed (usually just if subpoenaed). This is to protect their reputation as a business, so if you stick with the bigger companies, you should be OK.
Even if you would rather have complete control over all of your data, I highly recommend a starting on a VPS for its simplicity and ease of use, and if you decide you then want to self-host from home, migrating to your own physical machine is hardly impossible. Some reputable VPS companies include Linode and DigitalOcean, and while this tutorial will be using Linode, we don’t have a particular preference or affiliate.
The first thing to do is head over to https://www.linode.com and set up an account. If you do a web search for “Linode Promo Code” you can quite often find some for up to $20 credit. That will allow you to try the services out for some time before making a financial commitment. As a side note, Linode is typically very easy to cancel if you decide to go that route, so don’t worry about having to deal with an impossible to cancel account that has your credit card number. Once you have an account, you will probably want to select the $5/mo “Nanode” plan. This plan includes a virtual private server with 1 CPU core and 1GB of RAM, as well as 25GB of storage. If you suspect this won’t be enough for your needs, you can seamlessly upgrade to more hardware with only a couple of minutes of downtime.
When setting up the Linode, you will want to choose the Ubuntu 18.04 image, and the server closest to your location. Also, be sure to select a private IP address if it offers you the option, and set the root password to something secure, but that you also will not forget. Once you have it set up, navigate to https://cloud.linode.com/dashboard and click on your Linode. You should see a screen like this:
That number on the left, 22.214.171.124 is your IPv4 address. Make sure to write that down or save it somewhere as we will need it in a minute.
Once you’ve created your Linode and started a Nanode plan, the very next thing you will need is a domain name. These typically run from $10-$15 per year. You must purchase your domain name from a registrar. While your Linode account gave you an IP address, the domain name is going to act as a lookup for that IP address. When someone types in “mywebsite.domain” it will automatically navigate to the IP address of your Linode. There’s a multitude of registrars available, and somewhat ironically, we recommend using Google Domains. There’s a multitude of reasons for this. Many registrars operate shady business and billing practices, making it difficult to cancel, raising the price of your domain when it’s up for renewal, and charging extra for privacy. Google Domains has up-front, fair pricing , free privacy protection so that your name and address don’t have to be publicly listed, and a variety of other services such as Dynamic DNS (important if you decide to host from home) that other companies typically charge for. You’re welcome to use any registrar, but it is very much a buyer beware situation. If not using Google for anything is extremely important to you, Dreamhost is a good alternative. They aren’t as feature rich, but their pricing is fair and they are an extremely reputable company that does not engage in any known shady business practices.
Once you have a domain name selected, you need to set it to direct to your Linode’s IP address. How to do this will depend on what registrar you decided to use. For Google Domains, you will want to log in to your account, and select the DNS tab on the domain name:
Once inside the DNS page, you will want to scroll down to “Custom resource records” and we’re going to add a record:
In the field on the left, we’re going to put an @ symbol. This means that anything going to the root domain name that you just purchased will be affected by this DNS record. So any time you type in your website’s domain, this is what the computer will look up to see where to go. In the field on the right, if you click the drop-down menu, there’s a variety of options. Option A indicates that this is an IPv4 address we are redirecting to. IPv4 is a method of IP address distribution that the majority of the internet runs on. IPv6 is becoming more popular, and is indicated by the AAA record. You can have multiple types of records for @ if you want, so you could set it up to work with an IPv4 and an IPv6, both forwarding to your website, but we will just focus on the A record for now. The box that says 1H tells us how long this record will live. We set this to an hour, (1H), so every hour this will update. If you make a change to it, you will have to wait until the next update for the change to become effective. The final box on the right is where you are going to put the IP address of your Linode. So the bottom line is, we’re redirecting any traffic to your domain to go to the IPv4 address of your Linode. Then, on your Linode, we will put the content that we want to display. Make sure to click save, and we can move on to setting up the Linode.
Next, you will want to connect to your Linode and start setting up the software. This is where things start to get fun, since we will be customizing our little home-away from-home on the internet. Since Ubuntu Server (and pretty much all server operating systems) doesn’t have an actual desktop environment to cut down on processing overhead, we will do everything through a command line interface, or shell environment. To connect to this shell, we need to download the PuTTY software. PuTTY is an SSH client. SSH stands for “Secure Shell” and is a secure way to have a terminal on a remote system. You can download PuTTY from here. Grab the file that you need, depending on your operating system, and run it.
Once you have PutTTY open, you can type your IPv4 address into the Host Name field. Make sure that the port is set to 22, then, in the saved sessions field you can type an easy to remember name, and click the save button. You will need to make sure you have a saved session as we are going to modify it later. Once your session is saved, go ahead and select “Open”.
You may receive a PuTTY Security Alert, telling you that the key is not in your registry. That’s fine, as we have never connected to this host before, so just accept it. If you are using PuTTY frequently, and suddenly this pops up, then it might be cause for alarm because it’s saying that your connection to the server may have been intercepted.
Once connected, a black terminal window is going to appear. It will as you for an account to login as. For this, we’re going to enter “root” and the password is going to be whatever we made our root password when we set up the Linode. You will not be able to see the password characters as you type so don’t freak out if you can’t see them, as it is a security measure. Once you have logged in, you will be greeted with a system message, and a terminal at the bottom of the screen. Congratulations! You’ve now set up your first web server. We now have to get to configuring it.
Securing Your Server
OK, so the first thing we need to do is secure the web server. Right now, the only account is a root account. In Linux, the root account is like having a full administrator account on Windows, but even slightly more dangerous. There’s nothing the root account can’t access, or delete, even critical system files that could break the whole server. For this reason, we want to make a new, non-root account, and then prohibit login to the root account. To do this, we’re going to enter our very first terminal command:
Replace username with whatever you would like your username to be. The terminal will prompt you to enter the password for that user – make sure you can remember it. It will then prompt you for other information such as the name, phone number, etc. You can just hit enter without entering any data here to skip it, if you like. It will then ask you to verify if the information is correct. You can just enter “y” and hit enter again, and you should be done.
The next thing we need to do, is modify this user account so that they can run commands as a root user if necessary. This is generally preferred over having a root account because to run rood commands, you must enter the “sudo” command first, as well as your password periodically, for additional security. To make the new user a root user, we are going to enter:
usermod -aG sudo username
…where username is the user you just created, and sudo is the group that we’re adding it to. Now, we’re going to exit the PuTTY application, and reconnect. This time, instead of logging in as root, log in with the username and password that you just made.
The next thing we want to do, is prevent anyone from logging in as the root user. To accomplish this, we need to modify the SSH settings on the server, and tell it not to accept connections from the root account. The settings file is located in the /etc directory on the system. To get there, let’s start by getting our bearings. On the left hand side of the screen, you should see something like username@localhost:~$
The username portion is self explanatory. @localhost tells you you’re logged into the machine called “localhost”, and the :~ tells you that you’re in directory ~. The ~ directory is simply your user’s home directory. You can append the cd command with the directory you want to navigate to. For instance, you could type cd /etc to navigate to the /etc directory. If you typed cd etc without the slash at the front of the etc, it will assume that etc is inside the directory you’re currently in. The / tells it that you want to navigate to a root directory, at the base of the file system.
OK, let’s get our bearings now. If we type the command to list everything inside our current directory (which right now is ~), it shouldn’t display anything, as the directory is empty. So go ahead and type ls and see that nothing happens. Then, type:
The cd command tells the computer we would like to change your directory. The .. simply means you want to navigate to the parent directory of the one that you’re in. You should now be in the /home directory. If you enter ls again, you should see your user folder. That’s the one that you were just in. Type cd .. again, and then type ls one more time. This time, you should see a variety of folders such as bin, var, etc, and the directory you were just in, home. Also, your current directory should just be denoted by a / symbol. That is the root directory of the file system. Everything starts with a / symbol. You can use the / symbol to navigate directly to any directory, from anywhere in the server.
Don’t worry if this is confusing now, you will get the hang of it as you navigate around your server. Let’s get back to business, though. We want to edit the configuration file for the SSH software, which resides in /etc/ssh, so let’s enter:
This tells the computer that from the root directory, navigate to the etc folder, and then in the etc folder, navigate to the ssh folder. If you type ls inside of that /etc/ssh folder, you should see a list of files, one of which is named sshd_config. We’re going to edit this file, but before we do that, we’re going to make a backup copy, just in case we break it beyond repair. So run the following command:
sudo cp sshd_config sshd_config.backup
The sudo command tells the server that we want to run this command as the root user. We’re doing this because our user doesn’t have access to mess with the sshd_config file, but the root user does. The cp command stands for copy, the first argument is the file we want to copy, and the second argument is the name of the copied file. We didn’t specify a directory, so it will just copy it to the directory we’re currently in. To verify that the backup is there, run ls again. If it’s there, let’s go ahead and edit the original file to make the changes we need to:
sudo nano sshd_config
Again, sudo just says we are doing this with root privileges. Nano is the name of the default text editor on Ubuntu Server, and then the final argument is the name of the file we want to open. It should open up in a text editor. We want to scroll down until you see a section that looks like this:
# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes
The # on some of the lines indicates that they are commented out. Commented lines will be ignored by the software they interact with. It’s a handy method of turning things on and off without having to actually delete them. The only line that isn’t commented is the “Permit Root Login yes” line. We’re going to change that yes to no. It should look like this:
# Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes
Now, we’re going to save by pressing Ctrl + X. It will ask if you want to save. Type “y” and then keep the same file name when it prompts you for the file name. Now, we’ve updated our SSH configuration, so all that’s left is to restart the SSH service so that it reloads the configurations file. This can be done by entering:
sudo service ssh restart
This is a pretty basic command. Sudo says we’re running it as root, service tells the computer we’re messing with the services, ssh is the service we want to manipulate, and restart is the actual command of what we’re doing. You should not receive any feedback/errors if the command is successful. If you want, you can now exit PuTTY, and try reconnecting, but this time, logging in with the root login. You should receive an “Access denied” message, however, your user account should still work when you try that one.
That’s it for this tutorial. Congratulations! You’ve now found you internet island, and built the dock, so to speak. The next steps are going to be installing and running various services that will make your life easier, and free up your data. Feel free to post comments below, or ask any questions if you get stuck somewhere. The next article planned is a slightly more comprehensive discussion of security, how to better secure your server, and how to balance what theoretical best practices with realistic amounts of time and effort, as security truly can be an endless rabbit hole. After that, we will dive into installing some popular, open source services to use.
Why name this series “Antikythera?” It is named after the famous Antikythera mechanism, found in a Roman-era shipwreck off the coast of the Greek island Antikythera. The mechanism likely served as an astrological calendar, making it one of the first known automated computers. The interesting thing about the mechanism is that it predates any similar technology by over 1000 years, implying that the technology was at some point lost. We feel that this is a suiting metaphor in the face of the rapid balkanization of the internet, and as open communication gradually fades away. Additionally, the metaphor serves to remind us that if even the ancient Greeks could figure out computers, surely no challenge is beyond our abilities.