Home Lab Series | Part 2 | Hardening SSH login

If you’re utilizing SSH for device access, is it secure? The questions you may ask yourself: is your SSH login robust? Are default accounts in use? Is your device exposed to the internet, potentially vulnerable to prying eyes? Consider the digital fingerprint you leave across the web; an attacker, through OSINT, might compile a wordlist to exploit weak passwords via a dictionary attack.

This article delves into best practices to harden your device’s SSH login.

Steps

1. Limiting SSH Access
2. Modifying SSH config

Limiting SSH Access

Why limit the SSH access?

You may not need to provide SSH login access to all accounts on your device(s). For example, enabling SSH login for the root account with a weak password could potentially expose vulnerabilities, allowing attackers to brute force their way into the account or guess the password.

By default the pi user or user account that created while customization doesn’t require a password while elevating itself to root.

Create a new user

While logged in with your default account enter the following commands to create a user. I do recommend using a complex password with minimum 14 characters or more in length.

sudo adduser <username>

Example sudo adduser testuser

Disabling Default account

Once you have a new account created lets go ahead and disable the default pi account

Do test out your login with new user account before disabling pi user.

sudo usermod --lock --expiredate 1 pi

Create user group

We will create a user group specific for SSH login. This will allow you to add users under the group whom you want to have SSH access.

Creating different user groups for different role based purpose helps in managing and limiting users access to the system. This approach is called as role-based access control (RBAC)

Enter the following commands to create a user:

sudo groupadd <groupame> 

Example: sudo groupadd sshgroup

You can add users to the group by entering the command below.

sudo usermod -aG <groupname> <username> 

Example: sudo usermod -aG sshgroup testuser

Setting up Key-based Authentication

Using keys, for SSH (Se­cure Shell) is a safer and easier alternative to password authentication. Instead of relying on a password for access, the key-based login method relies on cryptographic keys. We generate a pair of cryptographic keys: one private, and one public. The private key stays with the client system. The public key goes to the server/system.

Generating SSH Key Pair:

On your local host machine (client), on a terminal window enter the following command to generate an SSH key pair

ssh-keygen -t ed25519 -a 600

-t ed25519: Specifies the type of key to create, in this case, an Ed25519 key. Ed25519 is a type of elliptic curve cryptography and is considered secure and efficient.

-a 600: Specifies the number of key derivation function (KDF) rounds.

Copy Public Key to Server:

Use the following command to copy your public key to the remote server. Replace user with your actual username and server_ip

ssh-copy-id -i <pub key> <username>@<server_ip>

Test your SSH connection by connecting to your server ssh username@server_ip

Modifying SSH config

Modifying ssh configurations ensure to an access control is in place basically what’s allowed and how you can connect to your server. The main configuration file for the SSH daemon is typically located at /etc/ssh/sshd_config on Linux systems. In our case Raspbian is a linux OS :P

Disabling Root Login:

Disabling root login is generally recommended. Instead, use a regular user account and then switch to the root user using sudor or a similar mechanism after logging in.

PermitRootLogin no

Diabling Password Authentication:

Disabling password authentication in favor of key-based authentication enhances security by reducing the risk of brute-force attacks.

PasswordAuthentication no

Allowing only users from a Group(s):

Limit SSH access to specific groups. This helps in controlling who can connect to the server. This

AllowGroups sshgroup

Port:

Changing the default SSH port (22) can help mitigate automated attacks targeting the default port. However, be cautious with this change to avoid locking yourself out.

Port: 2299

PermitEmptyPasswords:

Ensure that empty passwords are not allowed to enhance security.

PermitEmptyPasswords no

PubkeyAuthentication:

Confirm that public key authentication is enabled. This is a more secure method compared to password authentication.

PubkeyAuthentication yes

Protocol:

Ensure that you’re using SSH protocol version 2, as it includes security improvements over version 1.

Protocol 2

UsePAM:

Use PAM (Pluggable Authentication Modules) for additional authentication and session management. This is generally enabled by default and is really optional to set up a PAM solution for your DIY homeserver. In this case we do not need a PAM solution hence having it disabled.

UsePAM no 

If you are integrating a PAM solution, set the option to UsePAM yes

X11Forwarding:

X11 forwarding allows graphical applications to be run on a remote server but displayed on your local machine. While X11 forwarding can be useful, it also introduces potential security risks, especially if you are connecting to untrusted servers.

X11Forwarding no

Enable Connection Timeouts

This is to enhance the security of your SSH server, you can configure connection timeouts to automatically terminate idle SSH connections after a certain period. This helps to mitigate the risk of unauthorized access and potential security threats.

With the below configurations, the server will send keep alive message to client every 100 seconds and will terminate the session after 3 attempts. This configuration will disconnect unresponsive SSH clients after approximately 5 minutes.

ClientAliveInterval 100
ClientAliveCountMax 3

ClientAliveInterval Set the interval at which the server will send a keep-alive message to the client (in seconds).

ClientAliveCountMax Set the maximum number of client alive messages the server will send before disconnecting the client.

After making the changes, restart the SSH service for the configuration to take effect :).

sudo systemctl restart ssh.

Want to show your appreciation?

If you enjoyed this article or my other content, consider buying me a coffee. Your support helps me create more!

Support for honest content, directly to the author.