---
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.

Check out my post on [Tailscale](https://blog.ahmza.com/posts/no-more-port-forwarding/)

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
a good idea to [setup automatic updates](https://blog.ahmza.com/posts/setting-up-automatic-updates)
however if you want more control then using [Ansible to update Remote Machines](https://blog.ahmza.com/posts/ansible-to-manage-remote-servers)
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

## Conclusion