In this recipe, we will learn how to provide additional security measures in order to harden the secure shell environment. The Secure Shell (SSH) is the basic toolkit that provides remote access to your server. The actual distance to the remote machine is negligible, but the shell environment enables you to perform maintenance, upgrades, the installation of packages and file transfers; you can also facilitate whatever action you need to carry out as the administrator in a secure environment. It is an important tool; as the gateway to your system, it is the purpose of this recipe to show you how to perform a few rudimentary configuration changes that will serve to protect your server from unwanted guests.
To complete this recipe, you will require a minimal installation of the CentOS 7 operating system with root privileges, a console-based text editor of your choice, and a connection to the Internet in order to download additional packages. It is assumed that your server already maintains at least one non-root-based administration account that can use the new features provided by this recipe.
The role of SSH will be vital if you are forced to administer your server from a remote location, and for this reason it is essential that a few basic steps are provided to keep it safe:
root
and create a backup of the original configuration file by typing the following command:cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sshd
configuration file by typing the following:vi /etc/ssh/sshd_config
#LoginGraceTime 2m
LoginGraceTime 30
#PermitRootLogin yes
PermitRootLogin no
X11Forwarding yes
X11Forwarding no
systemctl restart sshd
exit
.SSH is a vital service that enables you to access your server remotely. A server administrator cannot work without it. In this recipe, you were shown how to make that service a little more secure.
So, what did we learn from this experience?
We began the recipe by creating a backup copy of our original main sshd
configuration file. The next step was to open and edit it. The configuration file for SSH maintains a long list of settings that is ideal for most internal needs, but for a server in a production environment it is often advised that the default SSH configuration file will need changing to suit your particular needs. In this respect, the first step was to make a recommended change to the login grace time, LoginGraceTime 30
. Instead of the default two minutes, the preceding value will allow only up to 30 seconds. This is the period of time where a user may be connected but will have not begun the authentication process; the lower the number, the fewer unauthenticated connections are kept open. Following this, we then removed the ability of a remote user to log in as the root user by using the PermitRootLogin no
directive. In most cases, this is a must and a remote server should not allow a direct root login unless the server is in a controlled environment. The main reason behind this is to reduce the risk of getting hacked. The first thing every SSH hacker tries to crack is the password for the user root. If you disallow root login, an attacker needs to guess the user name as well, which is far more complex. The next setting simply disabled X11Forwarding
. In situations like these, it is often a good idea to apply the phrase "if you do not use it, disable it". To complete the recipe, you were required to restart the SSH server in order to allow the changes to take immediate effect and start a new SSH session with the intention of making sure that the modifications did indeed work as expected. No system is ever safe, but having done this you can now relax, safe in the knowledge of having made the SSH server a little bit safer.
There are a few more topics to cover to make your SSH server even more secure: we should change the SSH port number and show you how to limit SSH access to specific system users.
Port 22 is the default port used by all SSH servers, and changing the port number used can go a small way to increase the overall security of your server. Again, open the main SSH daemon configuration file, sshd_config
. Now, scroll down and locate the following line that reads:
#Port 22
Remove the leading #
character (uncomment) and change the port number to another value by replacing XXXX
with an appropriate port number:
Port XXXX
You must ensure that the new port number is not already in use, and when complete, save the file and close it. It is important to remember that any changes made here are reflected in your firewall configuration. So, we need to open the new port in firewalld as well. Set the new port via the environment variable NEWPORT
(replace XXXX
with your new SSH port), then execute the following sed
command to change the SSH firewalld service file and reload the firewalld
daemon afterwards (for details, read the firewall recipe in this chapter):
NEWPORT=XXXX sed "s/port="22"/port="$NEWPORT"/g" /usr/lib/firewalld/services/ssh.xml > /etc/firewalld/services/ssh.xml firewall-cmd --reload
Also, we have to tell SELinux (see Chapter 14, Working with SELinux to learn more about it) about the port change because it is restricted to port 22 by default. Make sure that the SELinux tools have been installed, then create a security label for our custom port, replacing XXXX
with your changed port number:
yum install -y policycoreutils-python semanage port -a -t ssh_port_t -p tcp XXXX
Finally restart the sshd service to apply our port change.
By default, all valid users on the system are allowed to log in and enjoy the benefit of SSH. However, a more secure policy is to only allow a predetermined list of users or groups to log in. When henry
, james
, and helen
represent valid SSH users on the system, in the sshd_config
add this line to read as follows:
AllowUsers henry james helen
Alternatively, you can use the following method to enable any user that is a member of a valid administration group to log in. When admin represents a valid SSH group on the system, add this line to read as follows:
AllowGroups admin
When you have finished, save and close the file before restarting the SSH service.