2025-06-05 14:58:36 +01:00
|
|
|
---
|
|
|
|
|
title: Hardening Linux - An Update to Securing SSH
|
|
|
|
|
description: "A Guide to Making Linux a Little more secure"
|
|
|
|
|
tags: ["Linux", "Ubuntu"]
|
|
|
|
|
author: "ahmza"
|
|
|
|
|
date: 2025-06-05T15:34:10+01:00
|
|
|
|
|
draft: true
|
|
|
|
|
weight:
|
|
|
|
|
featureimage:
|
|
|
|
|
lastmod:
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
{{< alert icon="fire" >}}
|
|
|
|
|
> - This Guide assumes a Linux -> Linux SSH Session
|
|
|
|
|
> - Please take care with production systems
|
|
|
|
|
> - I take no responsibility for misconfigured systems and lockouts
|
|
|
|
|
> - Try in a VM first and thank me later :)
|
|
|
|
|
> - My Commands will be for Ubuntu Server 24.04
|
|
|
|
|
{{< /alert >}}
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Introduction
|
|
|
|
|
This guide will go over the basic steps of hardening a Linux machine with a
|
|
|
|
|
focus on remote access. The reason this is important is because when we begin to
|
|
|
|
|
expose services to the internet and make them publicly accessible then that means
|
|
|
|
|
anyone can probe around.
|
|
|
|
|
|
|
|
|
|
There are better ways around this especially if you are the only user, or If
|
|
|
|
|
your users dont mind taking an extra step before being able to access your
|
|
|
|
|
resources. If you have not heard of _Overlay Networks_ before they're similar to
|
|
|
|
|
VPNs however do not need any open ports as they use NAT Punching AKA Hole
|
|
|
|
|
Punching.
|
|
|
|
|
|
2025-06-13 11:04:24 +01:00
|
|
|
Check out my post on [Tailscale](/posts/no-more-port-forwarding/)
|
2025-06-05 14:58:36 +01:00
|
|
|
|
|
|
|
|
regardless, it's always a good idea to implement good security practice so
|
|
|
|
|
follow along and get your remote systems secure !!
|
|
|
|
|
|
|
|
|
|
## Initial Steps
|
|
|
|
|
|
|
|
|
|
Before we get into the meat and potatos of this guide, it would be a good idea
|
|
|
|
|
to go over the following steps, especially if you are configuring a new install.
|
|
|
|
|
|
|
|
|
|
### Software Updates
|
|
|
|
|
Software updates are key for security as they will often include security
|
|
|
|
|
patches. Depending on your flavour of Linux this command will vary.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
sudo apt update && sudo apt upgrade
|
|
|
|
|
```
|
|
|
|
|
{{< alert "bell" >}}
|
|
|
|
|
If you do not expect to be logging into this remote machine very often it may be
|
2025-06-13 11:04:24 +01:00
|
|
|
a good idea to [setup automatic updates](/posts/setting-up-automatic-updates)
|
|
|
|
|
however if you want more control then using [Ansible to update Remote Machines](/posts/ansible-to-manage-remote-servers)
|
2025-06-05 14:58:36 +01:00
|
|
|
would be a better option.
|
|
|
|
|
{{< /alert >}}
|
|
|
|
|
|
|
|
|
|
### User Accounts
|
|
|
|
|
It's not a good idea to continue to use a root account after install, it's much
|
|
|
|
|
more secure to setup another user account with sudo access. The reason is the
|
|
|
|
|
root account has complete control over the system, where a user account is more
|
|
|
|
|
restricted by default. As well as this logging is more granular with different
|
|
|
|
|
user accounts.
|
|
|
|
|
|
|
|
|
|
The following command will allow you to create a new user, it will also ask you
|
|
|
|
|
some questions about user information however the only required fields are the
|
|
|
|
|
username and password if you want one.
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
adduser username
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
now we can add our newly created user to the sudo group to give admin permissions
|
|
|
|
|
|
|
|
|
|
``` bash
|
|
|
|
|
usermod -aG sudo username
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
{{< alert "bell" >}}
|
|
|
|
|
Remember to replace username with your desired username
|
|
|
|
|
{{< /alert >}}
|
|
|
|
|
|
|
|
|
|
you can now logout of root and log back in as your user. Further action on the
|
|
|
|
|
server should now be executed from this user account.
|
|
|
|
|
|
|
|
|
|
## Creating SSH Keys
|
|
|
|
|
Now that you have your own user account, we can create an SSH key for it. An SSH
|
|
|
|
|
Key is a Public and Private key pair which allow client and server to
|
|
|
|
|
authenticate using Public Key cryptography. Public Key cryptography is much
|
|
|
|
|
harder to crack compared to a password, as well as this we no longer need to
|
|
|
|
|
send passwords across networks which can be at risk of interception.
|
|
|
|
|
|
|
|
|
|
SSH can also be more convenient once you set up ssh-agent which will be covered
|
|
|
|
|
later in the guide, with password authentication you need to enter a password
|
|
|
|
|
everytime, however with ssh-agent you can enter your ssh-key password once and
|
|
|
|
|
it remains unlocked for the remainder of the session.
|
|
|
|
|
|
|
|
|
|
{{< alert "fire" >}}
|
|
|
|
|
**IMPORTANT:** **NEVER** share your private ssh key ... it's private for a reason.
|
|
|
|
|
{{< /alert >}}
|
|
|
|
|
|
|
|
|
|
By running the following command you will create an ssh-key !!
|
|
|
|
|
```bash
|
|
|
|
|
ssh-keygen -t ed25519 -C NameYourKey
|
|
|
|
|
```
|
|
|
|
|
- `-t` - specifies the type of cryptographic algorithm we will use
|
|
|
|
|
- `-C` - notice it's capital, A name for your ssh keys. I usually give them the
|
|
|
|
|
hostname of the local machine
|
|
|
|
|
|
|
|
|
|
|
2025-06-13 11:04:24 +01:00
|
|
|
|
|
|
|
|
## Conclusion
|