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>

Disabling Default account

#

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

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.

Enter the following commands to create a user:

sudo groupadd <groupame> 

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

sudo usermod -aG <groupname> <username> 

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

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>

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.

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 

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

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

sudo systemctl restart ssh.