Initial tasks I do after a fresh Ubuntu server install

Set to local time zone

Setting this makes it easier to read timestamps (e.g. in logs)

to check the current time use ’timedatectl':

scribbles@testserver:~$ timedatectl
               Local time: Fri 2023-09-01 06:40:52 UTC
           Universal time: Fri 2023-09-01 06:40:52 UTC
                 RTC time: Fri 2023-09-01 06:40:52
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
scribbles@testserver:~$

you can use ’timedatectl list-timezones’ to check what yours is, but this is a huge alphbetical list that could take some time to find the one you need (especially towards the end of the alphabet). To narrow down the list pipe the output to grep with your country name:

scribbles@testserver:~$ timedatectl list-timezones | grep Australia
Australia/ACT
Australia/Adelaide
Australia/Brisbane
Australia/Broken_Hill
Australia/Canberra
Australia/Currie
Australia/Darwin
Australia/Eucla
Australia/Hobart
Australia/LHI
Australia/Lindeman
Australia/Lord_Howe
Australia/Melbourne
Australia/NSW
Australia/North
Australia/Perth
Australia/Queensland
Australia/South
Australia/Sydney
Australia/Tasmania
Australia/Victoria
Australia/West
Australia/Yancowinna
scribbles@testserver:~$

then set using the appropriate timezone (this requires sudo/root privilege):

scribbles@testserver:~$ sudo timedatectl set-timezone Australia/Sydney
scribbles@testserver:~$ timedatectl
               Local time: Fri 2023-09-01 16:48:13 AEST
           Universal time: Fri 2023-09-01 06:48:13 UTC
                 RTC time: Fri 2023-09-01 06:48:13
                Time zone: Australia/Sydney (AEST, +1000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
scribbles@testserver:~$

Setup UFW firewall

Although Ubuntu is pretty secure by default, I always prefer to setup and enable UFW firewall (Uncomplicated FireWall - a frontend for iptables). As I nearly always access my machines and VMs via SSH, it is important to enable these connections before enabling the firewall, to avoid locking myself out.

UFW is not usually enabled on a fresh install. This can be checked like this:

scribbles@testserver:~$ sudo ufw status verbose
Status: inactive

Adding the rules for SSH is easy (the command can have many options, which I wont cover here, such as IPV4 or IPV6 only, only allows access from specified IP addresses/ranges & more):

scribbles@testserver:~$ sudo ufw allow ssh
Rules updated
Rules updated (v6)

When you are connected via SSH and enter the command to enable the firewall, it warns you that the connection may be disrupted:

scribbles@testserver:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

You can check the status again to confirm that UFW is active and the rules for SSH have been applied:

scribbles@testserver:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

Setup SSH access

SSH server should be automatically installed on Ubuntu server default install, but not on desktop version.

scribbles@testDesktop:~$ ssh [email protected]
[email protected]'s password:

Generate SSH keys (all keys etc used are on temporary VMs just for this post)

Linux:

scribbles@testDesktop:~$ ssh-keygen -t ed25519 -b 4096 -C "whatever comment I want"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/scribbles/.ssh/id_ed25519): /home/scribbles/.ssh/nameofkey
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/scribbles/.ssh/nameofkey
Your public key has been saved in /home/scribbles/.ssh/nameofkey.pub
The key fingerprint is:
SHA256:3LmuscpF1uHAQbi5MYE2kpisTCNsI6T1+1HPSEpQNRQ whatever comment I want
The key's randomart image is:
+--[ED25519 256]--+
|++...o.=E.       |
|*Oo.+.o. o       |
|O oo...+= .      |
|..   o== O o     |
|    . o+S B      |
|     ..+   .     |
|      . o .      |
|     . . +       |
|      o.o..      |
+----[SHA256]-----+
scribbles@testDesktop:~$

Windows:

For key generation, Windows Terminal (from Win10 onwards at least) works the same.

Copy keys to server

Linux:

scribbles@testDesktop:~$ ssh-copy-id -i ~/.ssh/nameofkey.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/scribbles/.ssh/nameofkey.pub"
The authenticity of host '192.168.0.195 (192.168.0.195)' can't be established.
ED25519 key fingerprint is SHA256:ZF+NfE6it2IM2JInB05oVPzf9rhYPvScosMUV9GD4h4.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

scribbles@testDesktop:~$

Windows: I am not aware of an equivalent to ‘ssh-copy-id’ as default on Windows, so I use ‘scp’ and then move the key into ‘authorized_keys’. In Windows terminal (this Windows PC already has an SSH key for the server using a passphrase):

PS C:\Users\scribbles> scp C:\Users\scribbles\.ssh/nameofkey.pub testserver:/home/scribbles/.ssh
Enter passphrase for key 'C:\Users\scribbles/\.ssh\scribbles-testserver':
config                                                                                100% 3277     1.6MB/s   00:00
PS C:\Users\scribbles>

Then, on the server, navigate to the .ssh directory & add the key:

scribbles@testserver:~/.ssh$ ls -l
total 8
-rw------- 1 scribbles scribbles  208 Sep  1 17:00 authorized_keys
-rw-rw-r-- 1 scribbles scribbles 3277 Sep  1 17:07 nameofkey.pub
scribbles@testserver:~/.ssh$ cat nameofkey.pub >> authorized_keys
scribbles@testserver:~/.ssh$

If this is the only key on the client system, you can try logging in using the command suggested in the ssh-copy-id output. If there are lots of keys (I have about 20 each on my main desktop & laptop), it is better to use a config file (see next part).

SSH config file

Creating a config file for ssh can make it easier to manage and use multiple ssh keys for different remote hosts. To get started simply create a file in the .ssh folder named config and add the appropriate details:

Host testserver
        HostName testserver
        User scribbles
        IdentityFile ~/.ssh/testserver
        IdentitiesOnly yes

In the above example:

Host = give the entry a name
HostName = should match the hostname of the system and can be defined in DNS or /etc/hosts (see below)
User = the user name on the remote host
IdentityFile = path and name of ssh key file
IdentitiesOnly = yes

The last two options specify which key to use to avoid the ‘Too many authentication failures’ error (which will occur if there are lots of ssh keys - Openssh normally defaults to trying every key in the local .ssh folder and blocking after 4 or 5 public key authentication attempts).

etc/hosts

Depending on the local DNS setup, it can be useful to add the ssh remotes to the ‘/etc/hosts’ file as below:

scribbles@laptop:~$ tail /etc/hosts
192.168.0.194   testdesktop
192.168.0.195   testserver

the entries here are simply IP address and a name (best to use hostname if set) and allows using the name in commands which will automatically map to the IP address (this also works for commands such as ‘ping’):

scribbles@laptop:~$ ping testserver
PING testserver (192.168.0.195) 56(84) bytes of data.
64 bytes from testserver (192.168.0.195): icmp_seq=1 ttl=64 time=22.2 ms
64 bytes from testserver (192.168.0.195): icmp_seq=2 ttl=64 time=2.09 ms
64 bytes from testserver (192.168.0.195): icmp_seq=3 ttl=64 time=24.1 ms
64 bytes from testserver (192.168.0.195): icmp_seq=4 ttl=64 time=24.1 ms

Change some SSH default options for security

Although SSH is reasonably secure by default, it is usually considered best practice to make some changes from the defaults, such as:

disable root login (obviously you need a user with ssh access before doing this)
disable password based login/allow login only with ssh keys (obviously you need to have created keys before doing this)

There are numerous other options, such as changing the default port number (but I feel this only really offers protection against the most basic of penetration attempts, those which ssh would probably stop anyway)

The default configuration file for SSH is found at /etc/ssh//etc/ssh/sshd_config (& can be viewed using the ‘cat’ command). One of the earlier lines in this file is ‘Include /etc/ssh/sshd_config.d/*.conf’. This tells the ssh daemon to first read any .conf files in the folder ‘sshd_config.d’ directory meaning the best way to change any of the defaults is to create your own ‘.conf’ file here (if one does not already exist). It is also useful to start the file name with a number as the files are read in name order (so a file starting with ‘10’ has priority over one starting with ‘20’.

Here is an example from one of my servers:

scribbles@someserver:~$ ls -l /etc/ssh/sshd_config.d/
total 4
-rw-r--r-- 1 root root 129 Sep  5  2022 10-my-sshd-stuff.conf
scribbles@someserver:~$ sudo cat /etc/ssh/sshd_config.d/10-my-sshd-stuff.conf
#My own SSHD settings
DebianBanner no
DisableForwarding yes
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no

If for some reason you prefer to change the main config file instead, before making changes it is always a good idea to make a copy of the original (to allow going back to the original if any errors are made with the changes). This is often done by using ‘sudo cp’ and adding .bak to the filename:

scribbles@testserver:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
scribbles@testserver:~$ ls -l /etc/ssh | grep sshd_config
-rw-r--r-- 1 root root   3254 Feb 26  2022 sshd_config
-rw-r--r-- 1 root root   3254 Sep  7 22:23 sshd_config.bak
drwxr-xr-x 2 root root   4096 Aug 31 14:27 sshd_config.d
scribbles@testserver:~$

To disable root login, open the file with ‘sudo nano’ (or whichever text editor you prefer)and find the line that contains ‘#PermitRootLogin’. The default is normally commented out by having the ‘#’ at the start of the line and has a value of ‘prohibit-password’. Remove the ‘#’ and change ‘prohibit-password’ to ’no’

To disable password based authentication uncomment the line for ‘PasswordAuthentication’ and change the value from ‘yes’ to ’no’

The examples below have most of the other lines removed for brevity.

Before:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

After:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

Whichever file you choose to edit, once you are done save and close the file, then reload ssh:

scribbles@testserver:~$ sudo systemctl reload sshd

If you now try to log in with password, it should fail:

PS C:\Users\scribbles> ssh  [email protected]
[email protected]: Permission denied (publickey).
PS C:\Users\scribbles>

fail2ban is a free and open-source IPS (Intrusion Prevention System) that can help protect against brute-force ssh login attempts. It does this by monitoring access attempts (e.g. from /var/log/auth.log) and then blocking IP addresses after the threshold is reached.

On Ubuntu server fail2ban requires that UFW firewall is already enabled.

The install and enable fail2ban,as well as check the status, simply use the following commands:

scribbles@testserver:~$ sudo apt install fail2ban
scribbles@testserver:~$ sudo systemctl enable fail2ban
scribbles@testserver:~$ sudo systemctl start fail2ban
scribbles@testserver:~$ sudo systemctl status fail2ban

To use fail2ban to protect ssh, we first need to set up the jail. The configuration files are found at /etc/fail2ban. The main jail config file is /etc/fail2ban/jail.conf, but (as this file warns you), this should not be edited. Instead you should either create a copy (e.g. /etc/fail2ban/jail.local)

However, the simplest way to set it up for ssh only is to create a .conf file in /etc/fail2ban/jail.d/

This file can have any name, as long as it has the .conf extension. An example name could be ‘mysshjail.conf’ & the required contents are simply:

[sshd]
enabled = true

Initial tasks Ubuntu Server

Initial tasks I do after a fresh Ubuntu server install

Set to local time zone

Setup UFW firewall

Setup SSH access

Generate SSH keys (all keys etc used are on temporary VMs just for this post)

Linux:

Windows:

Copy keys to server

SSH config file

etc/hosts

Change some SSH default options for security

Initial tasks I do after a fresh Ubuntu server install¶

Set to local time zone¶

Setup UFW firewall¶

Setup SSH access¶

Sign in via SSH using password authentication (weak security):¶

Generate SSH keys (all keys etc used are on temporary VMs just for this post)¶

Linux:¶

Windows:¶

Copy keys to server¶

SSH config file¶

etc/hosts¶

Change some SSH default options for security¶

fail2ban - more security against brute-force login attempts¶

Initial tasks I do after a fresh Ubuntu server install

Set to local time zone

Setup UFW firewall

Setup SSH access

Sign in via SSH using password authentication (weak security):

Generate SSH keys (all keys etc used are on temporary VMs just for this post)

Linux:

Windows:

Copy keys to server

SSH config file

etc/hosts

Change some SSH default options for security

fail2ban - more security against brute-force login attempts