SSH Security Guidelines

Secure Shell is an extremely secure protocol, but it is also one of the most frequently attacked protocols we see. Because of this, we have a set of practices we would like to see followed on systems that allow SSH either from large numbers of subnets (e.g. campus) or from outside campus.

A note on typography

For the rest of this document italics will be used for example lines in sshd_config.  Your system may locate this config file in either /etc/ssh/sshd_config or /etc/sshd_config.  When talking about a particular option the config line that is used to cause that is in parenthesis in italics.  These configs should be on their own line.

Limiting Remote Access Scope

Cyber Security is working towards reducing Georgia Tech’s potential attack surface by moving all remote access protocols, that do not have explicit reason for internet access, to be placed behind 2FA VPN. While SSH is considered a more secure protocol, placing SSH behind our 2FA VPN helps prevent brute force attacks, reduces authentication log file spam, and mitigates both known and unknown vulnerabilities from external threats. 

Root Account Security

The most common attack we see against SSH is brute forcing the root password.  If SSH is allowed off-campus or past limited subnets, please limit root login either by not allowing it (PermitRootLogin no) or by only allowing it with key negotiation (PermitRootLogin without-password)

Least Privilege

Limit access to only the necessary user accounts.

Normal Account Security

Non-root accounts should either not allow password login (PasswordAuthentication no) or user passwords should follow the GT password policies.  If password authentication is allowed then either two-factor should be employed or the system should not contain Category 3 data.

Limiting Failed Login Attempts

If the site is open off campus there should be some control to lock out someone password guessing.  

There are several options on how to do this:

  • Linux
    • Fail2ban
      • The fail2ban daemon watches log files and dynamically populates iptables rules to block abusive hosts at the host-based firewall level.  There is instructions on deploying it to block SSH for RHEL/CENTOS here.  For this, we would recommend blocking 30 minutes after 10 failed logins.  This is the easiest to configure solution.
    • Pam_shield
      • pam_shield provides a similar solution to fail2ban but instead of watching log files it inserts itself into the login process in PAM.
    • Pam_tally
      • pam_tally and pam_tally2 provide methods for locking a user account that has too many failed logins.  This is the most fragile of the three systems noted because it can lock out a legitimate user from anywhere when someone at a particular IP address tries to brute force them.
  • Windows
    • Windows offers the ability to restrict login attempts by updating the machine’s Local Security Policy. This includes a “account lockout threshold” and “account lockout duration”. For this, we would recommend blocking 30 minutes after 10 failed logins.


Systems should be patched on a regular schedule and no security patches older than 31 days should be unapplied.

Cortex XDR

The Cortex XDR agent should be installed on any machine which has SSH access available off campus. More information about the Cortex XDR agent, including installation instructions, can be found in the Cortex XDR KBs.

Vulnerability Scanning

Systems allowing ssh from off campus should have the Qualys Agent installed or alternatively be configured to allow Qualys to perform credentialed (authenticated) scanning.

Login Banner

If SSH is available off campus then /etc/issue should contain the GT Login Banner and the sshd config should contain Banner /etc/issue.  For certain countries this can cause a legal issue if we investigate an incident without having warned users that their connections may be investigated.

Log Management

Systems allowing ssh are allowing shell access to the GT network.  All such systems should save logs off of the box. One option for this is to export your logs to OIT’s Log Management service.  Systems, especially those available off campus, should also have a defined procedure for identifying unexpected logins to detect compromised accounts or intrusions.  Please note that the Log Management service imports logs but the systems administrator is still responsible for reading logs and identifying abnormal behavior.