Exposed SSH: Detection, Hardening, and Continuous Monitoring

Risk Assessment: When Is SSH Exposure a P1?

Unlike RDP, SSH exposure isn't automatically a P1. The risk depends heavily on configuration:

Quick Assessment Checklist

The Attack Landscape

Attack Volume Reality

• Average internet-facing SSH server: thousands to tens of thousands of failed login attempts daily
• Peak attack volume: significantly higher during active botnet campaigns
• Time to first attack after exposure: often within minutes of going online
• Common usernames targeted: root, admin, ubuntu, test, guest, user, oracle, postgres

Attack Types

• Brute force: Trying common passwords (123456, password, admin123)
• Credential stuffing: Using leaked username/password pairs from breaches
• Dictionary attacks: Systematic password guessing with wordlists
• Exploit attempts: Targeting known SSH vulnerabilities
• Post-compromise: Crypto mining, botnet recruitment, lateral movement

Secure vs. Insecure SSH Configuration

Insecure Configuration (Common Defaults)

Secure Configuration

Immediate Hardening Steps

If you've discovered exposed SSH with password authentication, take these steps immediately:

Step 1: Assess Current Risk (15 minutes)

• Check if password authentication is enabled: grep PasswordAuthentication /etc/ssh/sshd_config
• Check if root login is permitted: grep PermitRootLogin /etc/ssh/sshd_config
• Review recent authentication attempts: grep sshd /var/log/auth.log | tail -100
• Check for successful logins from unknown IPs

Step 2: Disable Password Authentication (30 minutes)

1. Generate SSH key pair on your local machine (if you don't have one)
2. Copy public key to server's authorized_keys
3. Test key-based login in new terminal (keep existing session open)
4. Edit /etc/ssh/sshd_config: set PasswordAuthentication no
5. Set PermitRootLogin no
6. Restart SSH service: sudo systemctl restart sshd
7. Verify password login is rejected

Step 3: Implement Rate Limiting (30 minutes)

• Install fail2ban: sudo apt install fail2ban
• Configure SSH jail with aggressive ban settings
• Consider iptables rate limiting as additional layer

Step 4: Check for Compromise (1 hour)

• Review all successful SSH logins during exposure period
• Check for new user accounts or authorized_keys modifications
• Look for unexpected processes, especially crypto miners
• Check cron jobs and systemd services for persistence
• Review network connections for suspicious outbound traffic

Long-Term Security Architecture

Option 1: Bastion Host / Jump Box

Route all SSH access through a hardened bastion host:

• Single, hardened entry point with maximum logging
• Internal servers not directly exposed to internet
• MFA on bastion authentication
• Session recording for audit

Option 2: VPN-Only Access

Require VPN before SSH is accessible:

• SSH port only accessible from VPN IP ranges
• VPN requires MFA
• Defense in depth—two authentication layers

Option 3: Zero Trust SSH

Modern identity-aware access:

• Certificate-based SSH authentication
• Short-lived certificates issued after MFA
• No static keys to manage or compromise
• Examples: Teleport, Boundary, Cloudflare Access

Monitoring & Detection

What to Monitor

• Failed authentication attempts: Baseline and alert on spikes
• Successful logins from new IPs: Especially for privileged accounts
• Logins outside business hours: Unusual access patterns
• Geographic anomalies: Logins from unexpected countries
• Configuration changes: Modifications to sshd_config or authorized_keys

Log Sources

• /var/log/auth.log (Debian/Ubuntu)
• /var/log/secure (RHEL/CentOS)
• Systemd journal: journalctl -u sshd
• Centralized SIEM for correlation across hosts

Alert Thresholds

Continuous SSH Monitoring: Detecting Configuration Drift

Hardening SSH is a point-in-time action. Without continuous monitoring, configurations drift: a colleague re-enables password auth to troubleshoot a login issue, a new server deploys with default settings, or a firewall rule change unexpectedly exposes port 22 on a production system.

Configuration drift is how security breaks quietly. External monitoring detects these changes by scanning from the outside — the same perspective an attacker has — and alerting when your SSH security posture degrades.

Related Security Guides

SSH exposure is often found alongside other attack surface issues. Review these related guides:

• Configuration Drift Guide — Understand how security configurations change over time and why drift detection is essential for ongoing SSH security.
• TLS/SSL Drift Guide — Certificate and cipher suite changes often affect the same servers running SSH — monitor both protocols.
• Exposed RDP Guide — RDP (port 3389) is even more dangerous than SSH when exposed. If you found SSH, check for RDP too.
• Exposed Admin Panels Guide — Web-based admin interfaces (Jenkins, phpMyAdmin, etc.) are often found on the same servers.
• Attack Surface Monitoring Guide — Learn how to continuously monitor for new SSH exposures before attackers find them.
• Exposed SSH Monitoring Solution — See how DriftAlarm continuously monitors for exposed SSH with automated drift alerts.

Summary: SSH Hardening Checklist