1. Setting up your server

PreviousSelf-Hosting: Three Easy Pieces Next2. Running Services

Last updated 6 months ago

1. Setting up your server

Servers

Servers are machines whose purpose is to provide a service or content over a network. They are typically administered remotely and only connect physically to power and a network. They "serve" content or services using software daemons. Their natural habitat is the datacenter, where they live in racks to survive off electricity and network data. While they are not able to reproduce, they have no natural predators, so their population is stable. Some breeds of server can be found in network/data closets where they live in a business. Fewer are still kept in captivity in private homes. Virtual servers are servers that are run under an emulator or hypervisor to provide a server-like environment using a software envelope which may be augmented with hardware support.

Finding a server to use

For small projects and little experiments, there are some no cost options you can try!

Renting Virtual Private Servers

A virtual private server, also known as a VPS, acts as an isolated, virtual environment on a physical server, which is owned and operated by a cloud or web hosting provider.

Procuring your own hardware

You can use anything as your server!
- Old Laptops
- Cheap NAS
- Single Board Computers (Raspberry Pi)
- Second-hand mini-pcs

We'll assume you have somehow gotten a server to work with, or if you're following the workshop, you should have something to work with already! The following guide will assuming your server is running Ubuntu, an operating system commonly found in servers.

Setting up your server

Get a username and password to your server, and SSH with a client:
- Terminal on MacOS
- Windows Terminal or PuTTy on Windows
- Any shell on Linux

ssh <username>:<ip-address>

You will be prompted for a password.

Creating a new user, and disabling root

This is important if you are logged into your server as root. As root is a common username, there will be people enumerating through common usernames on every possible IP address just to try their luck and compromise servers.

useradd -m -d /home/<username> -s /bin/bash <username> # Add user
usermod -a -G sudo,adm <username> # Give permissions
sudo passwd <username> # To create a password for the user

You might need to add the keyword sudo before all these commands. sudo basically allows us to run with superuser privileges.

Restricting SSH access

sudo nano /etc/ssh/sshd_config
Make sure that PermitRootLogin is set to something like prohibit-password
(Optional) Disable password logins, if you're very sure you can take care of your keypair: PasswordAuthentication no. Otherwise, maybe just leave them on for now especially if you have no way of recovering
Then, systemctl restart ssh

Setting up SSH Keys

What exactly are keys?

Keys are a secure way to log into remote computers without using passwords. Here's a simple explanation:

SSH keys come in pairs: a public key and a private key
The public key is like a padlock that you put on the remote server
The private key is like the key to that padlock, which you keep on your local computer
When you try to log in, your computer uses the private key to prove it can "unlock" the padlock
If successful, the server lets you in without asking for a password

This method is more secure than passwords because:

The private key never leaves your computer
It's extremely difficult for someone to guess or crack your key
Even if someone intercepts your login attempt, they can't see your private key

By using SSH keys, you can log in quickly and securely without typing a password each time.

Setting up your own ssh keys:

Setting up your own SSH Keys

While some service providers have a webshell, it’s much nice to be able to work in your own terminal (and significantly less laggy).

ssh-keygen -t ed25519
After that, take the pubkey string, then:
su user
mkdir .ssh
nano .ssh/authorized_keys
paste in pubkey string, save
chmod -R go-rwx .ssh

Now, you should be able to get a shell in your server, without any passwords!

Not familiar with the terminal/shell? Check out a quick introduction here:

Firewalls

While this is out of the scope of this workshop, setting up firewalls is another thing you should always do when setting up a server.

Domain Names

So, now we’ve got a server up and a way to access it. But you notice an IP address is kind of ugly and hard to remember… that’s where domain names come into play! If you’ve ever typed a website URL, you’ve effectively typed a domain name.

Well, how do IP Addresses turn into domain names? All you need to know is there are a lot of servers out there maintaining a large table of IP addresses to domain name mappings. These are known as DNS servers.

Getting your own domains

For purposes of this workshop, if you have the Github Student Developer Pack, you should be able to get a domain name from .tech for free for a year.

If you want to get a cool domain name, you can use this to compare prices from different registrars:

Every domain will have the following structure

<domain name>:<tld>
nushackers.org

For every domain, you can also have a bunch of records for subdomains

www.nushackers.org (www subdomain)
school.nushackers.org (school subdomain)

Configuring your own DNS Records

We’ll start by creating a bunch of A records:

Leaving the hostname blank will just lead to the main domain
Add * as the hostname will route all empty subdomains to a single address
Time to Live (TTL) is a field on DNS records that controls how long each record is valid and — as a result — how long it takes for record updates to reach your end users.

The industry standard is to use Cloudflare DNS, they have some great features such as Proxying.

Now, you have a cool domain for your server!