Some time ago I wrote an article entitled “I Opened My Connection To SSH Attacks, And These Were The Requests I Saw”, although I knew that there would be a significant number of attempts at gaining access too my SSH server, I really did not appreciate the sheer numbers that would be involved (over 100,000 attempts in 7 days).

SSH is a significant risk to your network security if not secured properly, that being the case what can you really do to secure it.

In this article we will look at methods you can use to help secure the SSH service on your device. Any instructions that are given focus on Red Hat based systems, however, these should easily be transferable to other flavors of Linux.

A word of caution, when carrying out the steps below (with the exception of the first) it is important to ensure that you keep an active session open. Failure to do so will cause you to be locked out if any of the steps goes wrong.

This may seem a bit counter productive to suggest in such an article, however, the only way of securing a service in reality is to disable it, therefore you must first consider whether you actually require the service. If you do not this is the only course of action that should be considered (IMHO)

Why: Enabling SSH on a local device may not appear risky but couple that with say, enabling DMZ mode on your router and you may find that you have accidentally exposed the service to the internet. Is the risk worth it to access that device you may only need to access once every few months? If the answer is no, accept that you will have to hook up a display and keyboard once in a while to correct configuration or to reboot that server.


systemctl stop sshd.service
systemctl disable sshd.service
firewall-cmd --remove-service=ssh

You have now successfully disabled SSH.

Why: Root is by far the most sought after account to compromise. Root has carte blanche to do anything that it likes, therefore it is important that the root access be limited as much as possible.

How: Firstly we must decide if any actions root would normally take (such as updating) is required to be carried out remotely. If the answer is yes then we of course need to give another user permissions to run actions as root. This should only be carried out on the most trusted of users and restricted to those that actually need it (irrespective of trust level). To do this we generally add the user to the group called ‘wheel’. This can be achieved by carrying out the following command using root (and ensuring you use a capital G):

usermod -aG wheel USERNAME
Sudo demonstration

Now that we have a user that can sudo as root we can disable root login. open /etc/ssh/sshd_config in vi and locate the line:

PermitRootLogin yes

and modify this t be

PermitRootLogin no

If the file does not contain such a line you can freely add it. Once modified save and close the file.

Now you can restart the service using the below command (this will not disconnect you):

systemctl restart sshd.service

You have now successfully disabled root login.

Why: Passwords in themselves can be insecure and tend to be reused. A much safer method is to use Public Key Authentication.

How: Before we can enable public key authentication we first have to configure our key and make it available on the server. For this, I am going to assume that you have a Linux machine to work from.

To create the keys type the following command on your local machine:


you will be asked a couple of questions. The first question askes where you would like to store the keys, accepting the default answer should be fine, you will then be asked for a password. although not required I would highly recommend setting up a password, this will mean that you will be prompted for a password when logging in, however it will be using the public/private key pair for the authentication.


Now that we have the keys generated we have to transfer them to the server. Linux makes this easy with the following command (replacing the user with the username you are setting up the key for and the IP and port for the SSH service on the server):

ssh-copy-id USER@IP -p PORT

You will be prompted for the password for the user once entered your generated key will be transferred to the server.

ssh-copy-id output

Now we need to configure SSH. Again we need to open /etc/ssh/sshd_config and locate the following two lines:

#PubkeyAuthentication yes
PasswordAuthentication yes

these should be modified as:

PubkeyAuthentication yes
PasswordAuthentication no

Next we need to restart SSH:

systemctl restart sshd.service

Test that you can still connect to the server. Do remember however that following these steps means that only this device can currently connect to the server, to allow other devices you will need to copy the keys to those devices as well.

After carrying out this step BACKUP YOUR KEYS. If you were to lose the keys you will have great difficulty in managing the server unless you have physical access.

Disclaimer: This is not a step that I generally take. This is essentially security by obscurity, that being said this can help protect against people scanning a range of IP’s for standard ports being open.

Why: The idea behind this is that in general an attacker is looking for low hanging fruit. Attackers are usually scanning a range of IP’s and looking for specific ports showing as open (such as the SSH port 22). By changing the port number you are removing these potential attackers from being a concern and are solely focused on the persistent attacker who is prepared to scan a large number of ports on your IP.

How: We first need to decide what port we are going to use.

Ports 0–1023 are reserved, therefore we should avoid these. Ideally we should choose a port between 1024 and 49151. There are no rules to say which and you can choose any port that is not already opened by another service.

Once you have decided upon the port, we need to modify the configuration file. Again open /etc/ssh/sshd_config and locate the line:

#Port 22

This is usually very close to the top. Replace this line with the line below (replacing port with the port number chosen above):


We now need to let the firewall know that we wish to use this port. Therefore execute the following commands (replacing port with the port number chosen above):

semanage port -a -t ssh_port_t -p tcp PORT
firewall-cmd --zone=public --add-port=PORT/tcp --permanent
firewall-cmd --remove-service=ssh
firewall-cmd --reload

We now need to restart ssh using the following command:

systemctl restart sshd.service

As usual double check that you can still connect. If using the command line you will now have to add the -p switch to the command. This is to tell ssh what port you wish to use. Such as:

ssh username@port -p 12345

Providing you can connect you have successfully changed the SSH port (as well as tidied the firewall to remove the standard SSH port)

It is of course vitally important that SSH on your network is secure as possible, failure to secure such a service can completely undermine any security measures you have put in place to protect your network.

What do you think of the steps above? Have I missed anything that you consider important? No doubt, over time I will add to this article, so far I have mainly focused on authentication however there are certainly other steps that we can take.

I am a keen tech enthusiast with a strong interests in voice interaction and security.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store