Ubuntu for Websites on Linode

Public Key Authentication with SSHOver the next few days, I’m going to be posting on some best practices for securing an Ubuntu Server for public access as a web server. Like any technology, especially those with web accessibility you want to work from the premise of ‘least access’ – granting just the necessary access required.

For this example, we’re going to assume you’re setting up a remote server in the cloud, such as Linode, AWS, or BlueHost. There are a lot of reasons for using a cloud hosting provider for your public website, instead of having your own physical servers, even if you’re a business with your own IT infrastructure. For this example we’ll be using a fresh Linode server:

If you don’t already have a Linode account, they’re really easy to setup. Start at this link, Linode and sign up and enter your billing and account information. Most accounts are activated instantly.

From there, create a new ‘node’ In this case I’m simply using a 1GB nanode, and then choose a data center location, ideally closest to your target audience.nanode

Next, we simply need to choose what Linux Distribution we want to use. From the Dashboard, click on the brand new Linode that was just created. Then click on “Deploy an image”. For this example we’re going to choose Ubuntu 18.04 LTS — it is strongly recommended that you choose an LTS build which stands for Long Term Support. For the swap space choose a number at least equal to your memory, so in the case of 1GB of memory, have a swap space of 1024 (up to about 2GB, at which point if you have more than 2 GB of memory, then just set the swap to 2GB). For everything else, I suggest keeping the default settings and then selecting a strong password that is different from your Linode account login. Back at the Node Dashboard, simply click “Boot”.

Out of the box, Linode requires you to use SSH login, so on a Windows PC, you’ll need a tool like PuTTY. (For other windows options, see this link. Also in 2018 openssh started showing up on some windows installations).

First you’ll need to get your new machines IP address, from the Node Dashboard, click on Remote Access. Towards the top you’ll see your public IP address.

In this case the public IP address is 192.81.131.223. (For those of you who see the 192 and think, wait, that is a private IP address, it’s not. The Private Space is only 192.168.0.0 – 192.168.255.255. Or in other words, 192.168.0.0/16)

If you’re not familiar with SSH or PuTTY, see How to Access Linode using PuTTY.

Once you’re connected you should install updates. From the SSH terminal, enter:

apt-get update && apt-get upgrade

Next, we’ll configure the server hostname:

hostnamectl set-hostname webserver

Then we’ll update the hosts file to reflect this hostname change. That way the server will resolve its own address locally, instead of attempting to query the DNS servers.

nano /etc/hosts

We’ll made additions for both our IPv4 and IPv6 addresses, as shown here:

Then press Control-X to exit, answer Y when asked to overwrite existing and press enter to confirm the same filename.

Update the timezone is optional. If your website is going to be used only in your local timezone, it might be convenient to use a local time zone. Otherwise the server defaults to UTC time which is preferred in many cases when you’re operating a websever that works across timezones. Otherwise you’re going to constantly have to check what time zone the server is using and then convert it, instead of always knowing that it is in UTC.

If you want to configure the local timezone on Ubuntu, then type:

dpkg-reconfigure tzdata

Follow the on-screen promots to select your local time zone. Since my best practice for web servers is to keep UTC, I’m going to omit this step. But in all cases, you can confirm your timezone by entering:

date

Next, we’re going to harden the SSH interface for remote access.

By default, password authentication is used to connect to your Linode via SSH. A cryptographic key-pair is more secure because a private key takes the place of a password, which is generally much more difficult to brute-force. In this section we’ll create a key-pair and configure the Linode to not accept passwords for SSH logins.

This process is done on your local computer, not on the server. See Public Key Authentication with SSH article for getting this setup.