Adding a new post about Hardening Linux Systems and SSH
This commit is contained in:
@@ -0,0 +1,113 @@
|
||||
---
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user