SSH Security Risks: Which Are the Most Common?

Overview of SSH

Secure Shell (SSH) is one of the most ubiquitous protocols used today for secure remote access, administration, and file transfers. It allows managing servers remotely over an encrypted connection. However, poor SSH security practices can inadvertently open doors for attackers.

While SSH itself is considered secure when properly implemented, misconfigurations and risky practices often lead to preventable breaches. According to studies, nearly half of all SSH servers on the internet allow password authentication, exposing them to brute force attacks.

In this article, we will overview some of the most common SSH security risks and how to address them through proper key management, access controls, updated SSH software, and other best practices. Adopting these measures can significantly reduce your SSH attack surface.

Common SSH Security Risks

Weak or Reused SSH Passwords
The most prevalent SSH security risk is the use of weak, default, or reused passwords for SSH authentication. SSH can allow password-based login, meaning attackers can brute force or guess weak passwords to gain access.

Strong, unique passwords are a must for SSH. However, password-based SSH authentication should be avoided entirely if possible in favor of SSH key-based authentication, as discussed below.

Outdated SSH Software
Like any software, older versions of SSH server and client implementations can harbor vulnerabilities that get patched over time. Using the latest supported version of OpenSSH or whichever SSH software you rely on is an important step.

Outdated SSH software with unpatched security holes can give attackers an opening to bypass authentication or execute remote commands. It's also important to keep system-level packages like OpenSSL updated that support SSH cryptography.

Allowing Password-Based SSH Authentication
Enabling password-based SSH login, instead of requiring public key authentication, leaves SSH much more vulnerable to brute force password guessing attacks. Limiting SSH to key-based auth prevents these types of credential attacks against SSH.

Servers that allow SSH password authentication are trivial for attackers to identify with tools like Shodan and target. Most organizations do not have a justifiable reason to permit password-based SSH access when other options like keys exist.

No Second Factor Authentication
For higher-security environments, relying solely on SSH keys for authentication still leaves a gap if a private key is compromised.

Adding a second authentication factor (2FA) through time-based one-time passwords (TOTP) apps or hardware tokens provides an important additional layer of protection. TOTP 2FA forces attackers to have both the SSH key and a dynamically generated code.

Unrestricted SSH Access
Overly permissive SSH access is another common mistake. Rather than restricting which users can SSH to which servers, some organizations enable unfiltered SSH access from anywhere.

Proper SSH access controls limit which source IP addresses, users, ports, and protocols can be used to connect over SSH. Unlimited SSH connectivity to critical servers invites lateral movement.

Poor SSH Key Management
Poor practices around SSH key generation, distribution, and rotation are also problematic. Weak SSH keys, reused keys, lack of key rotation, and improper storage of private keys all undermine SSH security.

Following SSH best practices for creating strong keys, rotating them regularly, securing private keys properly, and managing key distribution through a reputable system is important.

Use of Root Login
Enabling root login over SSH should be avoided except for specific use cases. Attackers will always target the highest privileges first when looking to move laterally on a breach.

Disallowing direct root login forces adversaries to first compromise a standard user account, then attempt privilege escalation, raising the barrier to full server control.

How to Reduce SSH Security Risks

Fortunately, there are specific measures administrators can take to lock down SSH security:

Mandate SSH Key Authentication

• Disable password-based SSH authentication methods like PasswordAuthentication
• Only permit public key authentication instead
• Require all personnel generate SSH key pairs to connect

Enable Two-Factor Authentication

• For SSH servers, integrate TOTP-based 2FA using Google Authenticator or hardware tokens
• Require both SSH private keys and a rotating token code to login

Restrict Access Controls

• Only allow SSH connectivity from dedicated jump boxes or bastions
• Limit source IP addresses able to establish SSH connections
• Configure user-based and group-based allow/deny access rules

Update SSH Software Regularly

• Run the latest supported versions of OpenSSH server and client software
• Patch and update associated libraries like OpenSSL that support SSH cryptography

Automate SSH Key Management

• Centralize storage and distribution of SSH keys through a secrets vault
• Automatically rotate SSH keys every 90 days or less
• Revoke SSH keys immediately if employees are off-boarded

Monitor and Log SSH Activities

• Send SSH logs to a security information event manager (SIEM)
• Alert on suspicious patterns like failed login attempts or unknown users

Disallow Root SSH Logins

• Prevent direct SSH access to root accounts except when absolutely required
• Force use of sudo privileges escalation model for more control

Summary

Poor SSH security practices continue to cause many preventable data breaches every year. Applying measures like updated software, key-based authentication, restricted access, key management, and 2FA adoption can help lock down this ubiquitous remote access protocol.

While SSH remains highly secure when configured properly, organizations cannot overlook the risks introduced through weak credentials, permissive access, outdated software, and key vulnerabilities. Following best practices and monitoring SSH server logs allows capitalizing on SSH security while limiting exposure to common attacks.

FAQs

Is SSH secure by default?
SSH itself is considered secure when configured properly. However, poor SSH key management, weak credentials, outdated software, and excessive access often undermine SSH security in practice. Following SSH best practices is required to realize its full security benefits.

Should SSH password authentication be allowed?
No, SSH password authentication should be prohibited in favor of SSH public key authentication. SSH key pairs provide much stronger security than passwords which are vulnerable to brute force attacks. Completely disabling the PasswordAuthentication option is recommended.

What is the most common SSH vulnerability?
The most common and easily preventable SSH vulnerability is allowing password-based SSH authentication. Servers permitting password-based auth invite brute forcing attacks. Enforcing key-based authentication blocks this common attack vector.

Does SSH provide encryption?
Yes, SSH provides strong symmetric encryption to encrypt the communication channel between SSH client and server. This protects passwords/keys and other data in transit from eavesdropping. Proper SSH configuration ensures all traffic is encrypted.

Should root SSH login be allowed?
Direct root logins via SSH should be disabled as a best practice. Users should first authenticate with their own SSH key, then escalate to root using sudo if needed. This raises the bar for attackers attempting to takeover root access on a server.

How often should SSH keys be rotated?
Industry best practice is to rotate SSH keys approximately every 90 days. More frequent rotation further limits exposure if a key is compromised. Old and unused SSH keys should be deleted when no longer needed.

What is the most secure SSH encryption algorithm?
The current recommended encryption algorithms for SSH are AES-256 or AES-128 for symmetric encryption, SHA-2 for data integrity, and ECDH/ECDSA using curve P-256/384 for asymmetric encryption. These provide the highest levels of security for SSH.