7 Warning Signs Your SSH Server Is Under Attack (And What To Do About It)

In today’s threat landscape, SSH servers remain prime targets for attackers seeking unauthorized access to your infrastructure. Unlike complex, sophisticated attacks that make headlines, most SSH compromises start with simple, detectable patterns that go unnoticed until significant damage occurs. This practical guide will help you recognize the warning signs of an SSH attack in progress and implement immediate countermeasures to protect your systems.

1. Unusual Login Attempt Patterns

What to look for: A sudden increase in failed login attempts is the most common indicator of a brute force attack. These typically appear as hundreds or thousands of failed authentication attempts, often targeting common usernames like “root,” “admin,” or “ubuntu.”

Real-world example: One financial services company noticed over 4,000 failed login attempts targeting their public-facing SSH server within a 24-hour period, all originating from IP addresses in a single geographic region.

What to do immediately:

• Implement IP-based rate limiting with fail2ban to automatically block IPs after multiple failed attempts
• Move SSH to a non-standard port (though this is security by obscurity, it reduces automated scanning traffic)
• Configure SSH alerts to notify your team when failed login attempts exceed normal thresholds

# Sample fail2ban configuration for SSH protection
enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 3600

2. Successful Logins from Unexpected Locations

What to look for: Authorized users typically access systems from predictable locations. Login events from unusual geographic regions, especially during non-business hours, warrant immediate investigation.

What to do immediately:

• Review the source IP address and correlate with known employee locations
• Check if the user should be accessing the system at that time
• When in doubt, temporarily disable the account and contact the user through alternative channels
• Consider implementing geo-based access restrictions for highly sensitive systems

3. Unusual Command Execution Patterns

What to look for: After gaining access, attackers typically run commands to explore the environment, escalate privileges, or establish persistence. Look for unusual command sequences like:

• Quick succession of commands exploring the file system (ls, cd, cat /etc/passwd)
• Privilege checking and escalation attempts (sudo -l, find / -perm -4000)
• Network scanning commands (netstat, ping, nmap)
• Downloads from unfamiliar URLs (curl, wget)

What to do immediately:

• Implement command logging to capture all executed commands in SSH sessions
• Set up alerts for suspicious command patterns
• Consider tools like auditd for comprehensive command auditing:

# Install auditd
sudo apt install auditd

# Configure command logging
sudo auditctl -a exit,always -F arch=b64 -S execve -k commands

4. Unusual File Access or Data Transfers

What to look for: Attackers often attempt to access sensitive files or exfiltrate data. Pay attention to:

• Access attempts to sensitive configuration files (/etc/shadow, SSH keys, configuration files)
• Large outbound data transfers, especially using tools like scp or sftp
• Creation of unexpected archive files (.zip, .tar.gz)

Real-world example: A tech company discovered a breach only after noticing nightly SSH sessions that were transferring compressed database backups to an external server, occurring automatically at 2 AM each day after the initial compromise.

What to do immediately:

• Implement file integrity monitoring on critical system files
• Set size limits and alerts for outbound SSH transfers
• Monitor for creation of unexpected archive files containing sensitive data

5. New or Modified Scheduled Tasks

What to look for: Attackers frequently establish persistence through scheduled tasks. Check for:

• New cron jobs, especially those running with elevated privileges
• Modifications to existing scheduled tasks
• Tasks that connect to external servers or run encrypted/obfuscated commands

What to do immediately:

• Regularly audit all scheduled tasks across your environment
• Implement alerts for changes to cron jobs and scheduled tasks
• Require approval processes for production cron job changes

# Simple cron job audit script
for user in $(cut -f1 -d: /etc/passwd); do
  echo "Cron jobs for $user:"
  sudo crontab -u $user -l 2>/dev/null || echo "No crontab for $user"
  echo ""
done

6. New or Modified SSH Keys

What to look for: Adding unauthorized SSH keys is a common persistence technique. Monitor for:

• New entries in authorized_keys files
• Modified SSH key permissions
• Unauthorized private keys stored on servers

What to do immediately:

• Implement file integrity monitoring on all authorized_keys files
• Centralize SSH key management with tools like Teleport or Okta Advanced Server Access
• Regularly audit and rotate SSH keys across your environment

# Find and check permissions on authorized_keys files
find /home -name "authorized_keys" -exec ls -la {} \;

7. SSH Service Modifications

What to look for: Sophisticated attackers may modify the SSH service itself to:

• Capture credentials by altering authentication modules
• Create backdoored versions that log credentials
• Change configuration to weaken security settings

What to do immediately:

• Verify SSH binary integrity using package management tools
• Monitor for unexpected changes to SSH configuration
• Implement application whitelisting to prevent unauthorized binaries from executing

# Verify SSH package integrity on Debian/Ubuntu
sudo apt-get --reinstall install openssh-server
# On RHEL/CentOS
sudo rpm -V openssh-server

Implement Proactive SSH Security Monitoring

Rather than waiting for an incident, implement these proactive monitoring practices:

1. Centralized SSH Log Collection

Collect all SSH logs in a central location for analysis:

# Configure rsyslog to forward SSH logs
# Add to /etc/rsyslog.conf
auth,authpriv.*  @logserver.example.com:514

2. Set Up Comprehensive SSH Monitoring

Tools like SSHwatch provide purpose-built SSH monitoring with minimal setup:

1. Get an API key from your SSHwatch dashboard
2. Install the lightweight agent on your Linux servers: curl -s https://install.sshwatch.com/install.sh | sudo bash -s -- --api-key YOUR_API_KEY
3. Configure alerts for suspicious activities:
   • Failed login thresholds
   • Logins from new locations
   • Specific high-risk command patterns
   • File access violations

3. Implement Simple Security Hardening Measures

Beyond monitoring, implement these SSH hardening practices:

• Disable password authentication and enforce key-based authentication: # In /etc/ssh/sshd_configPasswordAuthentication no
• Disable root login: # In /etc/ssh/sshd_configPermitRootLogin no
• Implement SSH access control with AllowUsers/AllowGroups: # In /etc/ssh/sshd_configAllowGroups ssh-users admin-team
• Enable two-factor authentication for SSH access

Real-World SSH Attack Response Plan

When you detect signs of a potential SSH compromise, follow this practical response workflow:

1. Contain the incident
   • Isolate the affected system from the network if possible
   • Disable the compromised account immediately
   • Preserve evidence by capturing memory and disk images if available
2. Investigate the scope
   • Check logs for lateral movement attempts
   • Review authentication logs to identify all potentially affected systems
   • Examine what data or systems the attacker accessed
3. Eradicate unauthorized access
   • Remove any malware or backdoors
   • Delete unauthorized SSH keys and credentials
   • Reset all passwords and rotate all SSH keys
4. Recovery and hardening
   • Rebuild systems from known good backups if possible
   • Implement additional monitoring and security controls
   • Conduct a lessons-learned review to improve detection capabilities

Case Study: How a Mid-Size E-commerce Company Detected an SSH Attack

A mid-size e-commerce company implemented basic SSH monitoring on their payment processing servers. Within two weeks, they detected unusual SSH access to a development server occurring at 3 AM local time.

Upon investigation, they discovered:

• The initial access came from compromised developer credentials
• The attacker had added a backdoor SSH key to maintain access
• Multiple attempts to access the production payment processing systems were made
• The existing access controls prevented lateral movement to sensitive financial systems

Because of their monitoring, they identified the breach within hours rather than the industry average of 277 days, preventing potential financial losses and regulatory penalties.

Conclusion

SSH attacks often follow predictable patterns that leave detectable traces. By implementing practical monitoring for these seven warning signs, you can identify and respond to potential breaches before significant damage occurs. Start with basic logging and alerting, then gradually enhance your security posture with more sophisticated monitoring tools.

Securing SSH doesn’t require complex, expensive solutions—it requires attention to the right signals and a practical approach to monitoring and response. Whether you leverage purpose-built tools like SSHwatch or implement open-source solutions, the most important step is simply to start monitoring today.

Ready to secure your SSH infrastructure? Get started with a free SSH security assessment to identify existing vulnerabilities in your environment.