Chapter 20. Configuring SSH

The following topics are covered in this chapter:

• Hardening the SSH Server

• Using Other Useful sshd Options

• Configuring Key-Based Authentication with Passphrases

The following RHCSA exam objective is covered in this chapter:

• Configure key-based authentication for SSH

Secure Shell (SSH) is among the most important utilities that system administrators use. In Chapter 5, “Connecting to Red Hat Enterprise Linux 8,” you learned how to use SSH to connect to a server using a password or key-based authentication. In this chapter, you learn about some of the more advanced configuration settings.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 20-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and ‘Review Questions.’”

1. Which of the following is not a common approach to prevent brute-force attacks against SSH servers?

a. Disable X11 forwarding

b. Have SSH listening on a nondefault port

c. Disable password login

d. Allow specific users only to log in

2. Which of the following successfully limits SSH server access to users bob and lisa only?

a. LimitUsers bob,lisa

b. AllowedUsers bob lisa

c. AllowUsers bob lisa

d. AllowedUsers bob,lisa

3. Which of the following commands must be used to provide nondefault port 2022 with the correct SELinux label?

a. semanage ports -m -t ssh_port_t -p 2022

b. semanage port -m -t ssh_port_t -p tcp 2022

c. semanage ports -a -t sshd_port_t -p tcp 2022

d. semanage port -a -t ssh_port_t -p tcp 2022

4. Which of the following descriptions is correct for the MaxAuthTries option?

a. After reaching the number of attempts specified here, the account will be locked.

b. This option specifies the maximum number of login attempts. After reaching half the number specified here, additional failures are logged.

c. After reaching the number of attempts specified here, the IP address where the login attempts come from is blocked.

d. The number specified here indicates the maximum number of login attempts per minute.

5. Which log file do you analyze to get information about failed SSH login attempts?

a. /var/log/auth

b. /var/log/authentication

c. /var/log/messages

d. /var/log/secure

6. SSH login in your test environment takes a long time. Which of the following options could be most likely responsible for the connection time problems?

a. UseLogin

b. GSSAPIAuthentication

c. UseDNS

d. TCPKeepAlive

7. Which of the following options is not used to keep SSH connections alive?

a. TCPKeepAlive

b. ClientAliveInterval

c. ClientAliveCountMax

d. UseDNS

8. Which file on an SSH client computer needs to be added to set the ServerKeepAliveInterval for an individual user?

a. ~/.ssh/ssh_config

b. ~/.ssh/config

c. /etc/ssh/config

d. /etc/ssh/ssh_config

9. Assuming that a passphrase-protected public/private key pair has already been created, how do you configure your session so that you have to enter the passphrase once only?

a. Copy the passphrase to the ~/.ssh/passphrase file.

b. Run ssh-add /bin/bash followed by ssh-agent.

c. Run ssh-agent /bin/bash followed by ssh-add.

d. This is not possible; you must enter the passphrase each time a connection is created.

10. The MaxSessions option can be used to tune the maximum number of sessions that can be open at the same time. Which value does it have by default?

a. 10

b. 25

c. 100

d. 1000

Foundation Topics

Hardening the SSH Server

SSH is an important and convenient solution that helps you establish remote connections to servers. It is also a dangerous solution. If your SSH server is visible directly from the Internet, you can be sure that sooner or later an intruder will try to connect to your server, intending to do harm.

Dictionary attacks are common against an SSH server. The attacker uses the fact that SSH servers usually offer their services on port 22 and that every Linux server has a root account. Based on that information, it is easy for an attacker to try to log in as root just by guessing the password. If the password uses limited complexity, and no additional security measures have been taken, sooner or later the intruder will be able to connect. Fortunately, you can take some measures to protect SSH servers against these kinds of attacks:

• Disable root login

• Disable password login

• Configure a nondefault port for SSH to listen on

• Allow specific users only to log in on SSH

In the following subsections, you learn what is involved in changing these options.

Limiting Root Access

The fact that SSH servers by default have root login enabled is the biggest security problem. Disabling root login is easy; you just have to modify the PermitRootLogin parameter in /etc/ssh/sshd_config and reload or restart the service. After restarting, verify that you really cannot log in as root anymore.

After disabling root login, you must specify the username you want to use for login by using ssh user@servername or ssh -l user servername. If you do not specify the username, it takes the name of the current user on the client who is trying to open an SSH session.

Configuring Alternative Ports

Many security problems on Linux servers start with a port scan issued by the attacker. Scanning all of the 65,535 ports that can potentially be listening takes a lot of time, but most port scans focus on known ports only, and SSH port 22 is always among these ports. Do not underestimate the risk of port scans. On several occasions, I found that an SSH port listening at port 22 was discovered within an hour after installation of the server.

To protect against port scans, you can configure your SSH server to listen on another port. By default, sshd_config contains the line Port 22 that tells SSH to listen on privileged port 22. To have SSH listen on another port, you must change port 22 into something else. Different ports can be used. You can choose to use a completely random port like 2022, but it can also be handy to configure SSH to listen on port 443.

Port 443 by default is assigned to web servers using Transport Layer Security (TLS) to offer encryption. If the users who want to access the SSH server are normally behind a proxy that allows traffic to ports 80 and 443 only, it may make sense to configure SSH to listen on port 443. You should realize, though, that by doing so port 443 cannot be used by your web server anymore; a port can be assigned to one service at a time only! So, do this only on a machine where you are not planning to run a TLS-enabled web server!

Modifying SELinux to Allow for Port Changes

After changing the SSH port, you also need to configure SELinux to allow for this change. Network ports are labeled with SELinux security labels to prevent services from accessing ports where they should not go. To allow a service to connect to a nondefault port, you need to use semanage port to change the label on the target port. Before doing so, it is a good idea to check whether the port already has a label. You can do this by using the semanage port -l command.

If the port does not have a security label set yet, use -a to add a label to the port. If a security label has been set already, use -m to modify the current security label. Use, for instance, the command semanage port -a -t ssh_port_t -p tcp 2022 to label port 2022 for access by sshd. If you want to relabel a port that already was in use by another service, you have to use semanage port -m to modify the current port assignment. This is needed if, for instance, you want SSH to be able to bind to port 443.

Limiting User Access

Many options for sshd can be found by just browsing through the sshd_config file. One of the most interesting options to use is AllowUsers. This option takes a space-separated list of all users that will be allowed login through SSH. Notice that this is a powerful option, limiting login to only these users. If the user root still needs to be able to directly log in, you have to include root as well in the list of allowed users.

When using this parameter, it makes sense thinking about which username you want to allow or deny access. In a scripted brute-force attack, intruders normally also try common usernames such as admin, Administrator, and jsmith. It is easy to add a layer of security by selecting an uncommon username. Notice the following about the AllowUsers parameter:

• The AllowUsers option by default does not appear anywhere in the default /etc/ssh/sshd_config file.

• The AllowUsers option is a better option than PermitRootLogin because it is more restrictive than just denying root to log in.

• If the AllowUsers option does not specify root, you can still become root by using su - after making a connection as a normal user.

A parameter that looks promising, but is misleading, is MaxAuthTries. You might think that this option locks access to the SSH login prompt after a maximum number of failed login attempts. Such functionality proves useful when connecting to a local server (of which configuration can easily be changed if so required), but on an SSH server with Internet access, it is a rather dangerous option, making it easy to perform a denial-of-service attack on the server. An intruder would only have to run a script that tries to log in as a specific user to block access for that user for an amount of time. That is why MaxAuthTries does not do what you might think it would do. It just starts logging failed login attempts after half the number of successful login attempts specified here.

Still, the MaxAuthTries option is useful. For analyzing security events related to your SSH server, it is not that interesting to know when a user by accident has typed a wrong password one or two times. It becomes interesting only after multiple failed attempts. The higher the number of attempts, the more likely it is that an intruder is trying to get in. SSH writes log information about failed login attempts to the AUTHPRIV syslog facility. By default, this facility is configured to write information about login failures to /var/log/secure.

In Exercise 20-1, you apply the common SSH options that have been discussed so far.

Using Other Useful sshd Options

Apart from the security-related options, there are some useful miscellaneous options that you can use to streamline SSH performance. In the next two subsections, you read about some of the most significant of these options.

Session Options

To start with, there is the GSSAPIAuthentication option, which on RHEL 8 is set to yes by default (which contradicts what the man page states about it). This option is useful in an environment where Kerberos authentication is used. If you do not have Kerberos in your environment, you might as well switch it off, because having this feature on slows down the authentication procedure.

The next interesting option is UseDNS. This option is on by default and instructs the SSH server to look up the remote hostname and check with DNS that the resolved hostname for the remote host maps back to the same IP address. Although this option has some security benefits, it also involves a significant performance penalty. If client connections are slow, make sure to set it to no, to switch off client hostname verification completely.

The third session-related option is MaxSessions. This specifies the maximum number of sessions that can be opened from one IP address simultaneously. If you are expecting multiple users to use the same IP address to log in to your SSH server, you might need to increase this option beyond its default value of 10.

Connection Keepalive Options

TCP connections in general are a relatively scarce resource, which is why connections that are not used for some time normally time out. You can use a few options to keep inactive connections alive for a longer period of time.

The TCPKeepAlive option is used to monitor whether the client is still available. Using this option (which is on by default) ensures that the connection is released for any machine that is inactive for a certain period of time. If used by itself, however, it might lead to a situation where unused connections are released as well, which is why it makes sense to use the ClientAliveInterval option. This option sets an interval, in seconds, after which the server sends a packet to the client if no activity has been detected. The ClientAliveCountMax parameter specifies how many of these packets should be sent. If the ClientAliveInterval is set to 30, and the ClientAliveCountMax is set to 10, for instance, inactive connections are kept alive for about 5 minutes. It is a good idea to set this to match the amount of time you want to keep inactive connections open.

The ClientAliveInterval and ClientAliveCountMax options can be specified on a server only. There is a client-side equivalent to these options also. If you cannot change the configuration of the SSH server, use the ServerAliveInterval and ServerAliveCountMax options to initiate connection keepalive traffic from the client machine. These options are set in the /etc/ssh/ssh_config file if they need to be applied for all users on that machine, or in ~/.ssh/config if applied for individual users.

Table 20-2 provides an overview of the most useful SSH options.

Configuring Key-Based Authentication with Passphrases

By default, password authentication is allowed on RHEL 8 SSH servers. If a public/private key pair is used, as explained in Chapter 5, this key pair is used first. If you want to allow public/private key-based authentication only and disable password-based authentication completely, set the PasswordAuthentication option to no.

When you use public/private keys, a passphrase can be used. Using a passphrase makes the key pair stronger. Not only does an intruder have to get access to the private key, but when he does, he must also know the passphrase to use the key. This is why for establishing client/server connections with public/private keys, it is recommended to use passphrases. Without further configuration, the use of passphrases would mean that users have to enter the passphrase every time before a connection can be created, and that is inconvenient.

To make working with passphrases a bit less complicated, the passphrase can be cached for a session. To do this, you need the ssh-agent and ssh-add commands. Assuming that the public/private key pair has already been created, this is an easy three-step procedure:

Step 1. Type ssh-agent /bin/bash to start the agent for the current (Bash) shell.

Step 2. Type ssh-add to add the passphrase for the current user’s private key. The key is now cached.

Step 3. Connect to the remote server. Notice that there is no longer a need to enter the passphrase.

This procedure needs to be repeated for all new sessions that are created.

Summary

In this chapter, you learned how to configure the SSH server with advanced options. You also learned how to set security options for sshd and how to set specific client options that help in keeping connections alive for a longer period.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have several choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix B; Chapter 26, “Final Preparation”; and the practice exams.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 20-3 lists a reference of these key topics and the page number on which each is found.

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

passphrase

connection

Review Questions

The questions that follow are meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.

1. Which two commands do you need to cache the passphrase that is set on your private key?

2. You want to disallow root login and only allow user lisa to log in to your server. How would you do that?

3. How do you configure your SSH server to listen on two different ports?

4. What is the name of the main SSH configuration file?

5. When configuring a cache to store the passphrase for your key, where will this passphrase be stored?

6. What is the name of the file that contains SSH client settings for all users?

7. Which setting should you use to set the maximum number of concurrent SSH sessions to 10?

8. How do you configure SELinux to allow SSH to bind to port 2022?

9. How do you configure the firewall on the SSH server to allow incoming connections to port 2022?

10. Which setting could you use if you experience long timeouts while trying to establish an SSH connection?

End-of-Chapter Lab

In this end-of-chapter lab, you configure SSH for enhanced security and optimized connection settings. Use server1 to set up the SSH server, and use server2 as the SSH client.

Lab 20.1

1. Configure your SSH server in such a way that inactive sessions will be kept open for at least one hour.

2. Secure your SSH server so that it listens on port 2022 only and that only user lisa is allowed to log in.

3. Test the settings from server2. Make sure that the firewall as well as SELinux are configured to support your settings.