We all know that it is important to secure your machines. I am going to show you some ways to do so. Some are trivial and should be set immediately, and some require more work. Part 2 will follow with the advanced options.

I'll use a random Linux machine with a SSH server as a reference (OpenBSD Secure Shell server according to systemd and config file). For the upcoming config changes, I have to edit /etc/ssh/sshd_config. It might differ from your setup.

Before we start

Please make sure that you test it on another machine first or have another way to access the machine. There are options to lock you out if it is not set up correctly!

And just as a side note: every change of the config file requires are restart of the SSH server.

Public key authentication

You can find a guide on how to use public key authentication in this post. I highly recommend to secure your server with public key authentication instead of password authentication.

Disable login attempts with empty passwords

PermitEmptyPasswords no

Fairly self-explanatory, but to make sure: allowing any account without a password to log into the system is a big no-no and should be turned off immediately.

Changing the ssh port

Port 2109

Well, some people think it is necessary, and some think it is useless to change the ssh port. It might not help against targeted attacks or scans, but it can help to avoid mass scans, bots, and script kiddies. Just remember to change the destination port on your clients as it deviates from the default 22.

Disable root login

PermitRootLogin no

Nobody should use the server as root, and therefore nobody should be able to login a root via ssh. To make sure you have an user with sudo created on the machine.

Disable SSHv1 and use SSHv2

Protocol 2

SSHv2 is usually the default, but it is worth making sure.

Set idle timeout interval

ClientAliveInterval 1800

The server uses this interval to check if the connection is still used and terminates the session when the client doesn't respond. With ClientAliveCountMax you can decide how often the server should send this message.

The used unit of the interval in seconds. I usually use 1800 seconds - or half an hour - but some suggest something way lower.

Restrict access to specific users or/and groups

AllowUsers a_this a_that AllowGroups ssh_login

This option is pretty straightforward and should be used. Just create a group like ssh_login and put the user into it if said user should be allowed to login in via ssh. With that, you don't have to edit the config file every time.

Set an authentication timer

LoginGraceTime 20

The authentication must happen in 20 seconds. The default is 2 minutes. This setting is not that important in my opinion.

Disable insecure ciphers and MACs

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms curve25519-sha256@libssh.org
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

There are even some more restrictive options, but I have not tested them myself.

Disable X11 Forwarding

X11Forwarding no

The security concern here is that X11 forwarding opens a channel from the server to the client. In an X11 session, the server can send specific X11 commands to the client, which can be dangerous if the server is compromised. Source

Disable SFTP subsystem

If you do not need SFTP, disable it. It is another attack vector, and something that is not usable, is harder to breach.

Just comment out the Subsystem sftp [...] out of the config.

Advanced options

I am going to write about more advanced hardening options that require more work and auditing your SSH access.

Some things I will cover and are worth looking into it:

Public key authentication

Fail2Ban

Logging

Auditing

Special thanks to ruffy for recommending disabling X11 forwarding and the SFTP subsystem.

More reading: