ahmza/blog-ahmza-com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated content in old posts.

Browse Source
This commit is contained in:
Hamza Ahmed
2024-01-05 23:54:51 +00:00
parent c916352195
commit cf68a1d2cc
10 changed files with 745 additions and 639 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/posts/securing-ssh.md
+159 -120
View File
@@ -10,50 +10,59 @@ description: "Ever wanted to make your SSH connections more secure. Read this"
canonicalURL: "https://blog.ahmza.com/Page%28/posts/securing-ssh.md%29"
cover:
image: "/webp/posts/secure-ssh/feature-anim.webp"
alt: "ssh-alt image" # alt text
caption: "<text>" # display caption under cover
relative: false # when using page bundles set this to true
image: "/webp/posts/secure-ssh/feature-anim.webp"
alt: "ssh-alt image" # alt text
caption: "<text>" # display caption under cover
relative: false # when using page bundles set this to true
showtoc: true
searchHidden: false
---
# **Introduction**
SSH is a widely used protocol to access remote devices. The problem
with SSH is at the authentication stage, Brute force attacks are one of
the ways an SSH connection can be compromised. A malicious actor will
constantly hammer the remote host with different passwords until it can
gain access. With further configuration of SSH we can make the service
a lot more secure.
SSH is a widely used protocol to access remote devices. The problem with SSH is
at the authentication stage, Brute force attacks are one of the ways an SSH
connection is compromised. A malicious actor will constantly hammer the
remote host with different passwords until it can gain access. With further
configuration of SSH we can make the service a lot more secure.
# **Configure SSH**
{{< video label="this is fine" webm="/webm/this-is-fine.webm" >}}
> **Famous last words:** Configuring SSH like many things in Linux is
as simple as editing a few config files
> **Famous last words:** Configuring SSH like many things in Linux is as simple
> as editing a few config files
Always be sure to **create a backup file** it's very easy to end up
locking yourself out of a device.
I would recommend practising on a machine that is not critical.
Always **create a backup file**, You can end up locking yourself out of a
device. Try this on a machine that is not critical.
## **Create SSH Keys**
SSH keys use public and private key encryption for authentication.
To create a set of keys, **on the client do:**
``` bash
ssh-keygen
```bash
ssh-keygen -t ecdsa -C <username>@<hostname>
```
You will be asked where you want to save the keys, **I recommend the \
default location** for less hair pulling later.
``` bash
- -t ecdsa - sets the key encryption type to _ecdsa_
- -C - Comment or name of the _SSH_ key. **Replace content in <>**
Where you want to save the keys, **I recommend the default location**
```bash
Enter file in which to save the key (/home/user/.ssh/id_rsa):
```
You will be asked to enter a password for the ssh keys, be sure to use
a strong password.
``` bash
Password for the ssh key, please use a strong password.
```bash
Enter passphrase (empty for no passphrase):
```
Once that is done you will see a confirmation screen like the one below
Once done you will see a confirmation screen like the one below
```
Output
Your identification has been saved in /home/user/.ssh/id_rsa
@@ -75,16 +84,16 @@ The key's randomart image is:
```
## **Copy SSH Keys**
> **Quick note:** user@host is the **username** on the **remeote host**
you would like to copy your public key to.
``` bash
```bash
ssh-copy-id user@host
```
> **Quick note:** user@host is the **username** on the **remeote host** you
> would like to copy your public key to.
**If asked to confirm the connection to the remote host answer yes**, this
happens when a new machine with an unknown identity wants to connect to
the client.
happens when a new machine with an unknown identity wants to connect.
```
Output
@@ -93,8 +102,7 @@ ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
```
You will then be asked to **enter a password** for the user on the remote
host
**Enter a password** for the user on the remote host
```
Output
@@ -103,42 +111,48 @@ Output
user@host's password:
```
If successful you should be able to access the device using the SSH key
Access the remote device using the SSH key
To verify this, SSH to the device and **it should ask for the Keys's
password not the users**
To verify this, SSH to the device and **it should ask for the Keys password not
the users**
``` bash
```bash
Enter passphrase for key '/home/user/.ssh/id_rsa':
```
## **Modify SSH Config**
create a backup
``` bash
```bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
```
open the original file in a text editor
``` bash
**NeoVim BTW!!**
```bash
sudo vim /etc/ssh/sshd_config
```
For a new user this might be daunting. Take your time and you will be
For a new _Linux_ user this might be daunting. Take your time and you will be
fine 😊
{{< video label="thats a big one" webm="/webm/thats-a-big-one.webm" >}}
**Lines we want to modify**
> **Quick note:** you may need to uncomment some lines as well as add a
few
> **Note:** uncomment lines as well as add missing lines
* Protocol 2 - add to line 15
* Port 2222 - modify line 17
* PermitRootLogin no - modify line 36
* Max Auth Tries 5 - modify line 38
* PasswordAuthentication no - modify line 60
* PermitEmptyPasswords no -modify line 61
* AllowUsers ahmza - add line 67
* ClientAliveInterval 180 - modify line 104
- Protocol 2
- Port 2222
- PermitRootLogin no
- Max Auth Tries 5
- PasswordAuthentication no
- PermitEmptyPasswords no
- AllowUsers <user>
- ClientAliveInterval 180
```
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
@@ -203,7 +217,7 @@ MaxAuthTries 5
PasswordAuthentication no
PermitEmptyPasswords no
AllowUsers ahmza
AllowUsers <user>
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
@@ -273,65 +287,74 @@ Subsystem sftp /usr/lib/openssh/sftp-server
{{< video label="not so bad" webm="/webm/wasnt-so-bad.webm" >}}
**Now lets explain what we just did**
* **Protocol 2** - released in 2006, SSH2 introduced improved
encryption algorithms.
* **Port 2222** - The port number can be whatever number you want.
Choose something other than 22 this will help hide your device from malicious actors
* **PermitRootLogin no** - If the root account were to be compromised
then the attacker has full control of the system so we stop it from being able to log in.
* **MaxAuthTries 5** - After 5 failed attempts the remote host blocks
requests from that IP for a period of time.
* **PasswordAuthentication no** - We have the SSH key installed so we
no longer need to have password authentication.
* **PermitEmptyPasswords no** - We don't want to allow empty passwords
to be used as authentication for obvious reasons.
* **AllowUsers username** - Add the usernames of users you want to be
able to connect to the remote host and other users trying to connect
will be dropped.
* **Client Alive Interval 180** - Drop the connection after a certain
period of inactivity
## **Check were able to connect**
- **Protocol 2** - released in 2006, SSH2 introduced improved encryption
algorithms.
- **Port 2222** - The port number can be whatever number you want. Choose
something other than 22 this will help hide your device from malicious actors
- **PermitRootLogin no** - If the root account gets compromised then the
attacker has full control so we stop root from logging in over ssh.
- **MaxAuthTries 5** - After 5 failed attempts the remote host blocks requests
from that IP for some of time.
- **PasswordAuthentication no** - The SSH key is installed, no need to have
password authentication.
- **PermitEmptyPasswords no** - Don't allow empty passwords
- **AllowUsers username** - Add the users you want to connect to the remote
host, others will be dropped.
- **Client Alive Interval 180** - Drop the connection after 180s of inactivity
## **Check ability to connect**
restart sshd service
``` bash
```bash
sudo systemctl restart sshd
```
**Keep the current SSH connection open** and create a new session.
If you are able to connect to the remote hosts then you are all set. If
not then you still have the initial connection to the remote host to
roll back the changes and troubleshoot.
If you connect to the remote host then you're set. If not then you still have
the initial connection to the remote host to roll back the changes and
troubleshoot.
# **Success**
{{< video label="clap" webm="/webm/clap.webm" >}}
# **Setting up** ***Fail2Ban***
_Fail2Ban_ is an intrusion prevention tool. Although we are slowing
bots down with MaxAuthTries the attacker is still able to carry on
brute forcing. Which is what Fail2Ban is for, it actually blocks the
connections from that IP.
# **Setting up** **_Fail2Ban_**
_Fail2Ban_ is an intrusion prevention tool. Although we slow down attackers with
with MaxAuthTries they can still carry on brute forcing. Which is what Fail2Ban
does, it actually blocks the connections from that IP.
## **Install** **_Fail2Ban_**
## **Install** ***Fail2Ban***
**We will install Fail2Ban on the remote host**
First upgrade any packages, then **install** ***Fail2Ban***
``` bash
First upgrade any packages, then **install** **_Fail2Ban_**
```bash
sudo apt update && sudo apt upgrade
sudo apt install fail2ban
```
Now we need to enable the service so it starts when the remote host
starts
``` bash
```bash
sudo systemctl enable --now fail2ban
```
## **Configure** ***Fail2Ban***
The Fail2Ban config file we want to edit is called **jail.local** located in **/etc/fail2ban/**
## **Configure** **_Fail2Ban_**
The config file we want to edit is **jail.local** located in **/etc/fail2ban/**
open jail.local in your editor of choice
``` bash
```bash
sudo vim /etc/fail2ban/jail.local
```
The config for _Fail2Ban_ is a lot shorter than sshd so this should be
quick
The config for _Fail2Ban_ is nice and short
```
[DEFAULT]
bantime = 8h
@@ -349,80 +372,96 @@ quick
**[Default]** - Settings in here apply to all jails
* **bantime** - how long the ban will last
* **ignoreip** - IP addresses to ignore
* **ignoreself** - stops from locking itself out
- **bantime** - how long the ban will last
- **ignoreip** - IP addresses to ignore
- **ignoreself** - stops from locking itself out
**[sshd]** - this is the jail for sshd
* **enabled** - decides weather the jail is active or not
* **port** - the port number the service
* **filter** - tells the jail which filter to use from /etc/fail2ban/filter.d
* **logpath** - where the log you want fail2ban to read is
* **maxretry** - Times the client can attempt a login before being banned
* **findtime** - An amount of time which maxretry must occur to trigger a
ban for example in 10 minutes if 3 failed login attempts are made the
ban the IP
- **enabled** - decides weather the jail is active or not
- **port** - the port number the service
- **filter** - tells the jail which filter to use from /etc/fail2ban/filter.d
- **logpath** - where the log you want fail2ban to read is
- **maxretry** - Times the client can attempt a login before being banned
- **findtime** - An amount of time which maxretry must occur to trigger a ban
for example in 10 minutes if 3 login attempts fail ban the IP
**Restart** ***Fail2Ban*** to load the configuration
``` bash
**Restart** **_Fail2Ban_** to load the configuration
```bash
sudo systemctl restart fail2ban
```
## **Testing** ***Fail2Ban***
## **Testing** **_Fail2Ban_**
To test Fail2Ban lets create a test user and set a password for the
user
``` bash
```bash
sudo useradd test
sudo passwd test
```
**open the sshd config**
``` bash
```bash
sudo vim /etc/ssh/sshd_config
```
modify the line **PasswordAuthentication** to say **yes** and add the test user to **AllowUsers**
``` bash
Modify the line **PasswordAuthentication** to say **yes** and add the test user
to **AllowUsers**
```bash
PasswordAuthentication yes
AllowUsers user test
```
**restart the sshd service**
``` bash
```bash
sudo systemctl restart sshd
```
Attempt to login to the remote host using the test account using an
incorrect password. After 3 failed attempts it should say connection
refused.
``` bash
Attempt to login to the remote host using the test account using an incorrect
password. After 3 failed attempts it should say connection refused.
```bash
ssh test@host -p 2222
```
_Fail2Ban_ should do something along the lines of ...
{{< video label="you shall not pass" webm="/webm/you-shall-not-pass.webm" >}}
log back in as your normal user, remove the test user and restore the
sshd config.
log back in as your normal user, remove the test user and restore the sshd
config.
**To remove the user**
``` bash
```bash
sudo userdel test
```
**restore the /etc/ssh/sshd_config file**
``` bash
```bash
sudo vim /etc/ssh/sshd_config
```
Set **PasswordAuthentication** back to **no** and remove test from **AllowUsers**
``` bash
```bash
PasswordAuthentication no
AllowUsers user
```
# **Conclusion**
well done, you managed to make it through all that !! At least now you
can be reassured that if them pesky brute-force attackers decide to
target your machine they wont have a fun time being in Jail 🤣 sorry
bad joke.
well done, you managed to make it through all that !! At least now you can be
reassured that if them pesky brute-force attackers decide to target your machine
they can have a fun time in Jail 🤣 sorry bad joke.
By now you have managed to setup an ssh key for a client and copy it to
a remote host, re-configure the sshd config to lockdown authentication
and last but not least install and configure Fail2Ban to block pesky
attackers.
and install and configure Fail2Ban to block pesky attackers.
{{< video label="proud" webm="/webm/proud.webm" >}}