Chapter #10: Network Operations (Manage Basic Networking)

As a system administrator, you will often have to log on to remote systems to perform a variety of administration tasks using a terminal emulator.

You will rarely sit in front of a real (physical) terminal, so you need to set up a way to log on remotely to the machines that you will be asked to manage.

In fact, that may be the last thing that you will have to do in front of a physical terminal. For security reasons, using Telnet for this purpose is not a good idea, as all traffic goes through the wire in unencrypted, plain text.

In addition, in this chapter, we will also review how to configure network services to start automatically at boot and learn how to set up network and hostname resolution statically or dynamically.

Installing and Securing SSH Communications

For you to be able to log on remotely to a RHEL box using SSH, you will have to install the openssh, openssh-clients, and openssh-servers packages.

The following command not only installs the remote login program but also the secure file transfer tool, as well as the remote file copy utility:

yum update && yum install openssh openssh-clients openssh-servers

Note that it’s a good idea to install the server counterparts, as you may want to use the same machine as both client and server at some point or another.

After installation, there are a couple of basic things that you need to take into account if you want to secure remote access to your SSH server.

The following settings should be present in the /etc/ssh/sshd_config file.

1. Change the Default SSH Port

Change the port where the sshd daemon will listen from 22 (the default value) to a high port (~2000 or greater), but first make sure the chosen port is not being used.

For example, let’s suppose you choose port 2500. Use netstat to check:

netstat -npltu | grep 2500

If netstat does not return anything, you can safely use port 2500 for sshd, and you should change the Port setting in the /etc/ssh/sshd_config file as follows:

Port 2500

2. Only Allow Protocol 2

SSH supports two major protocol versions: Protocol 1 and Protocol 2. However, Protocol 1 is outdated, insecure, and vulnerable to several known attacks, such as man-in-the-middle and packet injection.

To make sure your SSH server uses only the secure and modern version, you should explicitly allow only Protocol 2 in the SSH configuration file.

Protocol 2

3. Configure Authentication Timeout and Restrict Access

To enhance security, it's essential to limit both the time a user has to successfully log in and who is allowed to log in at all.

First, the LoginGraceTime directive controls how long (in this case, 2 minutes) the SSH server will wait for a user to authenticate. If the user fails to log in within that time, the connection is dropped, reducing the risk of brute-force attacks.

Next, disabling direct root login using PermitRootLogin no ensures that even if an attacker knows the root username, they won’t be able to access the system directly with elevated privileges. Instead, users must log in with a regular account and then elevate privileges using tools like sudo.

Finally, the AllowUsers directive defines which specific users are permitted to log in via SSH. This acts as an access control list, and in this example, only the user tecmint is allowed. This helps restrict login access to trusted individuals and prevents unauthorized users from even attempting to connect.

LoginGraceTime 2m
PermitRootLogin no
AllowUsers tecmint

4. Enable Key-Based Authentication

For improved security, it’s highly recommended to use key-based authentication instead of traditional password-based logins.

This method is not only more secure but also helps protect your server from brute-force attacks. To enforce key-based authentication, you'll need to make the following changes in your /etc/ssh/sshd_config file:

PasswordAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes

Setting PasswordAuthentication to no disables the use of passwords entirely, forcing all users to log in with a private SSH key that matches a public key stored on the server. The RSAAuthentication and PubkeyAuthentication directives ensure that public key methods are enabled and preferred.