Linux distributions, such as Red Hat Enterprise Linux (RHEL), dominate the enterprise and cloud computing sectors. One of the many reasons for the success and popularity of Linux is its support of convenient and straightforward remote access protocols, such as Secure Shell (SSH).
In the right hands, SSH’s ability to securely access remote servers enables access to any Linux server, regardless of the environment. The problem is that, in the wrong hands, SSH can be a security nightmare. Poorly configured SSH is the equivalent of buying the best and most expensive lock available for your front door and leaving your house keys under the doormat. To be truly effective, SSH needs to be configured correctly.
Given the vital role information technology plays in most aspects of modern life, the topic discussed in this article has implications that extend beyond the realm of a specific platform, RHEL, and the world of system administrators and cybersecurity experts. SSH security is a concern for software developers, managers, decision-makers, and the broader public. In this article, we present five simple steps to ensure that the S in SSH stands for ‘secure’. Based on SSH configuration settings recommended by the Center for Internet Security (CIS), we show you how to easily prevent your organization’s data and systems from being compromised by hackers. We will also show you how automated systems, such as those provided by CalCom, can help you.
What You Will Learn
- Why securing SSH on RHEL is critical
- How to disable root login over SSH
- What is key-based authentication
- How to restrict SSH access
- SSH configuration best practices
Secure Shell (SSH): What it is and Why it is Vulnerable
SSH provides a secure channel for remote access between computers. SSH is an industry standard supported by Linux distributions (RHEL), Unix-based platforms (FreeBSD, macOS), and non-Unix platforms (Windows). SSH utilizes a client-server architecture and public-key cryptography, enabling it to operate over insecure networks. Opening a remote SSH connection is as simple as opening a terminal window and typing a single command with some additional configuration parameters. To further simplify using SSH, graphical user interface (GUI) applications are widely available. Once the connection is established, you can perform any command or run any script as if it were running on your machine.
SSH’s simplicity is what makes it so dangerous. If properly configured, any unauthorized users will be denied access, and the commands and data passing over the connection will be free from interference and/or eavesdropping. For example, in cases where SSH servers are running legacy protocols, provide root access to all users, use weak authentication, and are poorly configured, they are vulnerable to attack. In April 2025, the Outlaw Linux Malware attack exploited SSH to propagate a large-scale botnet. Earlier in 2025, another SSH vulnerability was used to infect 1,000 WordPress sites with malicious code. In December 2024, poor SSH security facilitated the theft of Nokia’s source code.
5 Essential Configuration Steps as Recommended by CIS
Despite what seems to be an endless stream of bad news, many of these incidents could have been avoided by deploying properly configured SSH servers. Let’s now look at five different actions you can take today to improve the security of your RHEL. The configuration steps are described in the CIS Red Hat Enterprise Linux 9 Benchmark v2.0.0; the relevant section number is included next to each step title.
Many readers will be able to dive straight in, open an RHEL terminal window, and edit the SSH configuration file in their preferred editor, such as VI (VIM) or Emacs. Less experienced readers can open a terminal directly from the Linux desktop. You can also edit configuration files with the friendlier nano editor by typing the following:
nano /etc/ssh/sshd_config
Step 1: Update SSH Protocols (CIS 1.6)
The original version, known as SSH1, of the SSH protocol has many known security vulnerabilities and has been superseded by the more secure SSH2. One of the first configuration updates you should apply is to ensure that your system-wide crypto policy is set to one of the following: DEFAULT, FUTURE, or FIPS, rather than LEGACY. The DEFAULT and FUTURE options support TLS 1.2 and 1.3, IKEv2, and SSH2 protocols. DEFAULT uses RSA keys that are a minimum length of 2048 bits. FUTURE increases the minimum length of RSA keys to 3072 bits and prohibits the use of SHA-1 in signature algorithms. The Federal Information Processing Standard (FIPS) is a security standard mandated for use by U.S. federal agencies and their suppliers.
To update the policy, open a terminal window, and verify that the system-wide crypto policy is not LEGACY with this command:
grep -Pi '^\h*LEGACY\b' /etc/crypto-policies/config
If no data is returned, the policy is correctly configured. Otherwise, update the system-wide crypto policy by running this command:
update-crypto-policies --set <CRYPTO POLICY>
Where <CRYPTO POLICY> is the name of the policy. For example:
update-crypto-policies --set FUTUTRE
Then, activate the updated system-wide crypto policy with this command:
update-crypto-policies
Step 2: Disable X11 Forwarding (CIS 5.1.10)
Most system administrators access remote machines and view data or run commands via the terminal. The X11 forwarding protocol enables less skilled users to access a remote machine through a graphical application.
To disable X11 Forwarding, open the /etc/ssh/sshd_config configuration file. Locate the DisableForwarding parameter and verify that it is set to no:
DisableForwarding no
Step 3: Disable Empty Passwords (CIS 5.1.19)
The most basic level of SSH authentication is to log in with just a user name and without submitting a password. Behind the scenes, SSH does expect a password, but a configuration parameter is set to accept an empty password. This leaves any remote computer wide open.
To disable empty passwords, open /etc/ssh/sshd_config. Locate PermitEmptyPasswords and verify that it is set to no:
PermitEmptyPasswords no
Step 4: Disable SSH Root Login (CIS 5.1.20)
Like all Unix and Unix-inspired operating systems, such as Linux and Red Hat Enterprise Linux (RHEL), a hierarchical system of access privileges is in place. At the lowest levels, a user’s access and freedom of action are highly restricted. At the very top or root level, users (superusers) have unlimited access and are granted complete freedom of action. Therefore, to prevent a hostile takeover of a remote machine, it is essential to disable SSH root login.
To disable SSH root login, open /etc/ssh/sshd_config. Locate PermitRootLogin and verify that it is set to no.
PermitRootLogin noStep 5: Enable the Pluggable Authentication Module (CIS 5.1.21)
The Pluggable Authentication Module (PAM) interface provides a standard method for authenticating users across different applications. PAM can restrict remote access based on user session data, including IP address, time, and location. This means that you can limit remote user access by setting strict authentication requirements.
To enable PAM, open /etc/ssh/sshd_config. Locate UsePAM and verify that it is set to yes.
UsePAM yes
Conclusion and Next Steps: Securing SSH on RHEL
One of the reasons for the success and popularity of Linux distributions in enterprise and cloud computing is that they provide administrators and users with a comprehensive and versatile toolbox, which includes SSH. Like any tool, when safely configured and used correctly, it makes performing simple tasks effortless and complex tasks possible. As we have seen, SSH is ideal for accessing remote machines and performing a wide range of scenarios, from routine maintenance to complex debugging. Like freedom, the convenience of SSH requires eternal vigilance. If you fail to configure your SSH environment correctly and do not audit your SSH security, you will enable hostile parties to access your network and perform a wide range of malicious actions.
In this article, we walked you through five simple configuration tasks that will put Security back into Secure Shell (SSH). The CIS document we used as the source for this article has 19 additional configuration tasks in Section 5.1: Configure SSH Server. It includes detailed descriptions and, in many cases, provides automated scripts for your use. This article was written for an audience that transcends a specific platform (RHEL), level of technical expertise, or job title. To raise awareness of the vital role SSH plays in the world of cybersecurity, we encourage readers to share this article as widely as possible. An attack that propagates a botnet or attacks WordPress installations has an impact far beyond the machines that host the sites.
Key Takeaways
- SSH is a prime target for attackers
- Disabling root login strengthens security
- Key-based authentication is more secure than passwords
- Restricting SSH access reduces exposure
- Following best practices improves resilience
How CalCom Can Help You
CIS Red Hat Enterprise Linux 9 Benchmark v2.0.0 is a great way to secure your SSH configuration and system-wide RHEL security. If you want to move beyond running basic hardening scripts and deploy a fully automated, intelligent solution, then CalCom can help you with CalCom’s Hardening Suite (CHS). CHS doesn’t just apply a baseline; it learns your needs, identifies misconfigurations, tests changes, and continuously monitors, all without any disruptions. CalCom is ideal for enterprise environments, those looking to scale, or for low-risk hardening. To learn more, go to our resources page and download our datasheets and white papers.
