Join Trustwave at the 2023 Gartner Security & Risk Management Summit in London, September 26-28. Learn More

Join Trustwave at the 2023 Gartner Security & Risk Management Summit in London, September 26-28. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats

Securing SSH: What To Do and What Not To Do

An Uptick in Activity

Over the last week we've seen the compromise of a number of supercomputers through their SSH service. Given the increase in Work From Home (WFH), the security of remote, administrative based services is more important than ever. If we look at Shodan (Figure 1), we can see ~22 million SSH services. Given the sheer volume of SSH services on the Internet, it's hardly surprising that attacks are on the rise and that they are successful.


Screen Shot 2020-05-18 at 9.15.48 AM

Figure 1:  SSH Services by as identified by Shodan


It's also a popular service for the SpiderLabs penetration test team when looking to gain entry into a host or environment.  Given our long history compromising the service we wanted to give you some advice on how to properly secure the service from threat actors.


Recommendations for securing the SSH Service

The configuration file for SSH, sshd_config, has a large number of configurable options.  We would always recommend that options are considered for their security and context within an environment.  We'll list what we believe are the most important recommendations for securing the SSH service.

  • Ensure that the SSH service is running the latest, stable release.  Looking at OpenSSH, which is the most popular version of SSH, we can see from Figure 2 (below), that the number of associated CVEs is small, but that vulnerabilities still occur, therefore, ensuring that the latest version is running is important, especially if this is an Internet-facing service.


Screen Shot 2020-05-18 at 9.41.29 AM
 Figure 2: OpensSSH Vulnerabilities by Year (src:


  • Do not allow the root user (UID 0) to authenticate remotely. This can be achieved by setting PermitRootLogin to no from within the sshd_config file. Access to the privileged root user should be via sudo.
  • Set PermitEmptyPasswords to no. I would hope that this doesn't require too much explanation.
  • Disable password authentication (PasswordAuthentication), this will remove the ability for remote attackers to brute-force credentials using a username and password combination. Disabling password-based authentication leaves key-based authentication, which is significantly harder to brute-force.  
  • Configure the AllowUsers option, this will permit a pre-defined set of users to authenticate to the SSH service and disable the ability for all other users to authenticate.
  • Ensure the AddressFamily is correctly configured. This option allows you to determine which address family can be used, inet (use IPv4 only), inet6 (use IPv6 only) or any (both). We've previously blogged around the importance of IPv6 security.
  • While outside the scope of this blog post, we would recommend filtering the source IP address i.e. only allow trusted IP addresses to connect to the service, this can be implemented via IPTABLES or TCP Wrappers.

Security through obscurity

As a dedicated penetration testing team, we see many different types of SSH configurations.  Some of these configurations we believe add little or no value to the overall security posture of the service.  

  • Changing the port number. SSH, by default, listens on 22/tcp, moving this to a non-standard port will not hide the service. If there are any underlying issues with the SSH service they will be found regardless of the port that SSH listens on.
  • Removing the SSH banner. When performing port scanning, it is common for SSH to display its banner, which will often display its version and/or related information. Removing the SSH banner does not impact the underlying security of the service.

Final Thoughts

The SSH administrative service is a key component when looking to gain access to an environment, even more so with the WFH movement.  Ensuring its security is paramount when looking to create a robust and secure environment.