Elementary SSH security guide

What’s up, today I’m going to show you how you can improve much more the security of your SSH service, because, despite being a protocol that literally its forte is security, this does not mean that we can not add more layers of security on it, as you know, this protocol allows remote access to a remote or local device through a secure channel but, also this could allow cybercriminals to access the device in an unauthorized manner, and compromise the information that is there.

So how do we make it more secure? That’s where your buddy RaiN (that’s me) comes to the rescue.

First, the most elementary, do not use classic passwords, the power of a simple password can make the difference between the protection of your server and a quick and unauthorized access by a cybercriminal to your server, so always use strong passwords.

Next, it is highly recommended to use public/private key pairs (of course, the server must know the public keys of the users who have access).

As users, on the client computer we can run the command

this will basically create two files, /home/(user)/.ssh/id_rsa and /home/(user)/.ssh/id_rsa.pub (although we can rename them if we wish), the first file will be the private key and the second the public key. We can open the files with any text editor without problem to verify its content, but not to modify them since this would affect its correct operation.

Now we must add to our server id_rsa.pub at the end of all the file /home/(user_on_server)/.ssh/authorized_keys

With this, from now on, you will need to save the id_rsa file in your computer whenever you want to access the server, because this will be your access key to access in a more personalized and secure way than with a simple password.

Now, let’s better configure the /etc/ssh/sshd_config file and add some extra layers of security, we recommend you to open your sshd_config file and make the appropriate modifications.

First of all, do not allow empty passwords.

Also, it is important to limit the time we give the user to send us the password (with a couple of minutes is enough, although we can limit it more) by default this time is in seconds, to modify it we will use the following line of instructions, where I will specify 2 minutes (120 seconds)

Also, we are going to limit the number of attempts to login with a password, the number of failed passwords (in my case I set it to 2, because we will assume that the clients that will use the server, know their password perfectly, but you can set the desired amount).

So far so good? great, because at the beginning we mentioned the use of public and private keys as authentication method, and even though we use them, we can still be vulnerable that our server accepts authentication through passwords without more, so, if you did the above mentioned about creating a key pair and adding it to the hosts authorized to access the server, then you can follow this step because, with this instruction we force not to use passwords without more (it’s optional).

On the other hand, we will deny access to the root user and thus ensure that no one can access as this user via SSH.

Now, if a cybercriminal acts smart and tries to establish several connections to test different authentications, let’s stop him (with this we will be saying that maximum 2 simultaneous connections are in the SSH, you can adapt it to your requirements or those of your company).

Seguidamente, cambiaremos el puerto por defecto del SSH, y tu dirás, ¿en serio, eso aumentará la seguridad? pues sí, aunque no lo parezca, existen muchísimos ataques automatizados a los puertos por defecto de los servicios, en este caso al 22 que es el puerto de común uso del protocolo SSH, así que colóquemoslo en otro puerto, por ejemplo el 65534

Another thing, but more than for security is to avoid unnecessary resource expenses, is to kick users when they have been inactive for a certain time and we do it with this instruction, in this case I set it to 10 minutes, we never know if our system administrator was just for water, let’s not exaggerate, but if he is already playing LoL games instead of working, then we have to take care of the server resources.

Another thing, but more than for security is to avoid unnecessary expenses of resources, is to kick the users when they have been inactive for a certain time and we do it with this instruction, in this case I set it to 10 minutes, we never know if our system administrator was just for water, let’s not exaggerate, but if he is already playing LoL games instead of working, then we have to take care of the server resources.

We can then set up a whitelist so that only certain users can access the system.

Finally, you can make it so that access is only allowed from the local network or that groups are created for the respective accesses to which the users should belong if they want to access

And these were some of the many ways that we can use to keep our SSH service secure, remember to keep your operating system and all the software on it updated, with this you are also improving the security of them and also drink water, water is life.