Overview
iKVM
Secure Login
Network Cards
Hard drives
SSHFS
Basic DNS
Website DNS
Certbot SSL
Apache and PHP
Maria DB
Mail Server Basics
Mail Server SSL
Mail Server Filters
Checklist
Backup

Secure Login

Note: This article series covers configuring Debian 12 for hosting multiple domains and web sites on a single dedicated server. As such, some strategies may be inappropriate for your environment. Sockets for example are appropriate for communication between services hosted on the same machine but not suited to a set up with distributed services (where you'd use ports). Please consult the overview for more information.

Once you've got root access to your new server, login and update and upgrade it. Obviously, replace the login details with yours:

Login as root from your terminal:

ssh root@< IP_address >

eg. ssh root@192.168.1.150

As it's a fresh install your username should be root but if it's something other than root and you've been given the root password, you'll need to change to the root user once you've logged in:

To change to the root user, once you're on the server:

su
< input the root password when prompted >

Update and upgrade the server:

apt update && apt upgrade

Once that's done we need to secure it.

DO NOT NEGLECT THIS SECTION!

We're going to set up a secure certificate pair to encrypt your login and connection and obfuscate things a bit to make a brute force attack less likely to succeed. We're also going to make your administrative login a bit safer.

You might think you can skip this part because your password is very strong and a brute force attack will never succeed. I thought that my 40+ character random string password was sufficient to protect me too until a brute force attack succeeded and the hacker ruined all my tidy configuration, turned my server into a zombie and had it sending spam and trying to brute force other servers in my data centre.

You also get complaints from your server service provider so you have to stop the bleeding. Either by trying to reverse and mitigate the changes or by completely re-installing it from scratch. This is one very good reason why regular backups are essential.

Assume that, given enough time, a brute force attack will ALWAYS eventually succeed - the only bottleneck you have is the speed of the network.

This might all sound grandiose and a bit confusing to begin with but I assure you it's pretty pipsqueek to set up and you'll be super-glad you did it.

First off, I recommend against logging in as root and instead creating a secondary user and using sudo to elevate your privileges when necessary. sudo stands for 'Super User Do' and makes your user temporarily as powerful as the root user in order to complete various tasks.

A default installation will prompt you to enter your password before giving you those extra powers and I recommend keeping that setting. Those few seconds whilst you're typing your password give your brain a moment to process what you're asking it to do and sometimes you'll realise you're about to do something silly and cancel the operation. Honestly, this will sometimes save your bottom!

Make sure you're the root user before doing the following (so su as above if not!).

Creating A Secondary User and Granting sudo Privileges

Install sudo:

apt install sudo

Create a new user

adduser < your new username >

Follow the prompts. You don't need to enter anything for most things but make sure you specify a password and remember it.

Add the new user to the sudo config

sudo visudo

Find the section in the file called 'User privilege specification' and add your new user, mine looks like:

# User privilege specification
root    ALL=(ALL:ALL) ALL
your_user ALL=(ALL:ALL) ALL

Also Add Your New User to the sudo group, this way you can secure a directory or files for users in the group:

usermod -aG sudo < your new username >

Generating a Secure Certificate Key-Pair and Securing ssh

Now we've granted sudo permissions to your new user, we're going to secure your login and connection to the server with a pair of secure certificates. One certificate is 'public', the other is 'private'.

Note that we generate the certificate pair on the client computer and only move around the public file. This is to avoid exposing the private file to the outside world.

It's simple enough, when a client attempts to log in, the server presents a public certificate and only grants access if the client can prove it owns the private certificate.

On your client computer in a terminal, generate a key pair:

ssh-keygen

It will suggest a name, I usually specify my own because I need to connect to multiple servers. It will also ask for a password, I like to specify one in case the file is stolen as it provides a layer of extra security.

Generally, on Ubuntu anyway, it will only ask you to provide the password once per session, so you'll provide it when you first log on but not need to for the rest of the day.

Upload the public key to the server:

ssh-copy-id -i ~/.ssh/< your_key > < your new username >@< IP_address >

If you get asked whether you trust the login type 'yes'. It always asks that the first time a user logs in.

Enter the password you set up for your new user.

ssh-copy-id will now copy the public file to the server. Type 'exit' to logout.

Login to the server with ssh

Now you'll be able to log in to your server using your new certificate security:

ssh < your new username >@< IP_address >

If you specified a custom name for your certificate, you may need to specify it using the -i option:

ssh i ~/.ssh/< your_key > < your new username >@< IP_address >

On Ubuntu I get a pop up requesting the certificate password, enter the password you specified.

You should now be logged in to your server under your new username.

Change the Port Number and Disallow Password Authentication

The ssh service usually listens on port 22, we're going to change that to a non-standard port and since we can now log in with our secure certificate we can also disallow password authentication.

Change the sshd config (ssh service configuration):

sudo nano /etc/ssh/sshd_config

Port 2222
...
PasswordAuthentication no

Restart the ssh Service:

sudo systemctl restart ssh.service

Logout:

exit

Log back in. Note -p 2222 specifies the port number we just specified:

ssh -p 2222 < your new username >@< IP_address >

Or if you're using a custom key:

ssh -p 2222 i ~/.ssh/< your_key > < your new username >@< IP_address >

Change the root password

We're now going to change the root password, this will stop anyone using KVM to physically log in to the server. Now your provider will not even be able to log in to your server.

I generate a long password by getting the md5 of some random file. If you're going to do it that way, make sure you pick a file that only you own as a persistent hacker might try the md5's for files in popular packages if they suspect you might have used one to generate a password.

Note that there are a few decent packages available to generate passwords on Debian, Google is your friend if you want to follow that route:

md5sum < some file >

On your server, login as root:

su

Or now that you've got sudo installed:

sudo -s

Change the root password:

passwd
< enter your new password >

exit

If I were you I'd now back up the secure certificates on your local PC (on Linux ~/.ssh/< your_key > - there'll be 2 files, one has the .pub extension) and make a note of your new long root password somewhere.

Remember, now the only way anyone can log in is with that private security file you generated earlier or by directly logging in as root on the hardware using your new root login credentials.

Like I said earlier, a brute force attack will always eventually succeed but now your attacker must guess your username and your private encryption key. Your root user cannot login via ssh with a password and there isn't a root ssh certificate set up!

You're now secure!

Note: After I've set up my network cards (I have 5 useable IP addresses with my dedicated.com server), I edit my sshd_config to only bind to 1 IP address (one I'm not using for anything else).

If you want to do that, after logging in to your server, edit your sshd_config file:

sudo nano /etc/ssh/sshd_config

ListenAddress < your_IP_address >

Restart the ssh Service (always double-check any changes to that file before restarting, you don't want to mess up your login). Remember that you must now specify that IP address in your ssh login string!:

sudo systemctl restart ssh.service

benosborne.com   |  Site Map