5 things you should do right now to secure SSH access to your server
Tags: security, webdev, devops, linux
Published: 2020-10-14 12:05:25

At ServerAuth our goal is to help improve your experience with SSH access management on your servers. We do this with our Platform and Agent and can make managing access simple!

Managing access is just one part of running a server, keeping it secure is another part. Over the last few months, we've been putting together some guides on how to set up and implement some basic things that will help keep your access secure.

It's worth noting, these will not secure your server entirely as these are for **securing your SSH access** not your server as a whole.

![Minions - Lets get started](https://media.giphy.com/media/Ln2dAW9oycjgmTpjX9/giphy.gif)

## 1 - Changing your SSH port

This is one of the most basic things you can do. Everyone who has had some experience with servers knows that SSH access is on port 22. If someone was trying to gain illegal access to your servers they will know automatically to try that port.

Changing the port number you use to SSH into your server is something simple and quick that can be implemented and instantly adds a complication for anyone trying to gain access to your server as they now need to find what port SSH is running on before they can log in.

To set this up, all you will need to do is edit one file, `/etc/ssh/sshd_config`. Set the correct config value, save and you're done!

You can read the full guide [here](https://serverauth.com/posts/how-to-change-your-ssh-port).

## 2 - Disable password login

By default, all users have a password that can be used to login to the server via SSH. If you have the IP address and the username / password you will be able to log in, no matter who you are!

By disabling password login, you are forcing users to [set up SSH Keys](https://serverauth.com/posts/set-up-ssh-keys) on your servers before they can log in. A SSH key is a special key that has a public and a private part. The private part of the key stays on the user's computer, the public part is placed on the server.

This means even if someone has given away the password to the server, only those users with a valid SSH key authorized on the server can log in. 

![Gandalf - You shall not pass](https://media.giphy.com/media/8abAbOrQ9rvLG/giphy.gif)

You can read the full guide on how to disable password login [here](https://serverauth.com/posts/how-to-disable-ssh-password-login).

## 3 - Setup password aging

At ServerAuth we always advocate removing the need for passwords and moving to SSH key login entirely. You can then use our Platform to easily manage who has access to your servers! However, we appreciate that it may not always be possible to setup. So to make passwords safer, you can implement Password Aging. 

As the naming suggests, this is the act of defining how old your passwords can be. The second your passwords age moves over the allowed limit in the config, the server will force you to change your password.

This adds the benefit that, your password will be changing more and therefore anyone who gains knowledge of your password will hopefully only know an old, expired password, keeping your server secure!

As mentioned, we would highly recommend disabling password logins entirely but if you cannot, read our guide on how to set up password aging [here](https://serverauth.com/posts/configure-password-aging-linux).

## 4 - Disable root access

In Linux, the root user is the top dog. This user has access to do **EVERYTHING**. If someone malicious was to gain access to your server via the root user, you're in for a _very_ bad time.

Thankfully, Linux provides us with a way of disabling access to the root user via SSH. Doing so will force a malicious user to gain access to your server via one of the other server accounts. Server accounts which hopefully you have created with fewer permissions than root and only given them access to what they need.

The benefits of this are obvious, by changing a single line within `/etc/ssh/sshd_config`, it can be the difference between losing a few folders versus losing a whole server.

You can read the full guide on how to set this up [here](https://serverauth.com/posts/how-to-disable-ssh-root-login)

## 5 - Two-Factor authentication for SSH

Two-factor authentication is becoming a standard across websites, with many forcing you to enable it to keep your account secure. Doing so means people now need to know your password **and** they need access to the app on your phone which generates the two-factor codes!

It's a great way to add extra security and peace of mind to your account / profile. But did you know you can set it up on your servers also?!

That's right, you can configure your servers so that anyone trying to log in via SSH will need to enter their password or have their SSH key on the server and then, add in a separate code generated via an app on their phones.

The process from a users point of view is extremely familiar to anyone who has used two-factor authentication before and is an amazing way to secure SSH access to your servers.

You can read our full guide on how to set it up [here](https://serverauth.com/posts/ssh-two-factor-authentication).

## Conclusion

![Shrek - Onions have layers, ogres have layers](https://media.giphy.com/media/22eVpVYpRhaE0/giphy.gif)

Server security should also have layers! Individually all these points don't amount to much, but added together they are simple and effective ways to secure SSH access to your servers!