SSH is the primary method for remote access on Linux systems, which also makes it one of the most common entry points for attackers. Investigating SSH compromise is a critical part of Linux forensics because attackers often use SSH to brute-force credentials, deploy backdoors, exfiltrate data, and maintain persistence.

This chapter explains how SSH works, indicators of compromise, key log locations, methods attackers use, and the forensic techniques needed to detect and analyze SSH intrusions.

Understanding How SSH Compromise Happens

Attackers typically compromise SSH through:

1. Brute-force attacks

Automated attempts using common credentials.

2. Credential theft

Passwords stolen via phishing, memory scraping, or system compromise.

3. Weak SSH configuration

Examples include:

Password authentication enabled
Root login allowed
No rate-limiting
Outdated SSH versions

4. Unauthorized SSH keys

Attackers insert their public keys for persistent, passwordless access.

Logs & Artifacts for SSH Investigation

SSH leaves traces across multiple logs and directories. These artifacts help determine if, when, and how compromise occurred.

1. SSH Authentication Logs (Primary Evidence)

Location depends on distro:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Look for patterns such as:

Failed login attempts

Failed password for invalid user admin from 192.168.1.10 port 58722 ssh2

Successful logins

Accepted password for root from 203.0.113.4 port 50544 ssh2

Public key authentication

Accepted publickey for user from 45.76.12.33 port 52241 ssh2

Brute-force attempts

Hundreds or thousands of failed attempts from the same IP or botnet.

2. /var/log/wtmp, btmp, utmp

Use built-in commands:

View login history:

last

View failed login attempts:

lastb

View currently logged-in users:

who

These logs reveal:

First/last login attempts
Time of entry
Source IPs
Failed brute-force attempts
Persistent attacker sessions

3. Authorized Keys (Persistence Check)

Attackers frequently add their SSH keys to bypass authentication.

Locations:

~/.ssh/authorized_keys
/root/.ssh/authorized_keys

Investigators should look for:

Unknown or duplicated public keys
Recently added keys
Keys with suspicious comments (hacker handles, emails)
Keys created during the time of compromise

Use file timestamps:

stat ~/.ssh/authorized_keys

If modified around the attack window, strong indicator of intrusion.

4. SSH Configuration File

Location:

/etc/ssh/sshd_config

Look for insecure or modified settings:

PermitRootLogin yes
PasswordAuthentication yes
PermitEmptyPasswords yes
PubkeyAuthentication no
Non-default port that attacker changed to hide activity
AuthorizedKeysCommand hijacking

Use timestamps:

stat /etc/ssh/sshd_config

If changed without admin approval → likely compromise.

5. Reverse Shell Indicators

Sometimes attackers use SSH to run commands or open tunnels:

Port forwarding usage

Check auth.log for:

channel 3: open failed: connect failed

Or run:

journalctl | grep -i "port forwarding"

Suspicious processes

ps aux | grep ssh

Look for:

SSH processes running with unknown users
Hidden tunnel commands (-R, -L, or -D switches)

6. Bash History (User-Level Evidence)

Check:

~/.bash_history
/root/.bash_history

Look for commands such as:

Download malware (wget, curl)
Adding users
Adding SSH keys
Creating cron jobs
Changing SSH port

Example malicious command:

echo "ssh-rsa AAAAB3..." >> ~/.ssh/authorized_keys

7. New or Suspicious Users

Check system accounts:

cat /etc/passwd

Look for:

Unexpected new users
Users added to sudo group
Users without passwords
Disabled accounts re-enabled

Also inspect:

/etc/group

Attackers commonly create stealth users like:

sysadmin2
backup
support
mysqladmin

8. Cron & Systemd Persistence After SSH Access

Attackers often set persistence after gaining SSH access.

Check cron directories:

/etc/crontab
/etc/cron.d/
/var/spool/cron/crontabs/

Check systemd services:

systemctl list-unit-files | grep enabled

Look for:

Services running attacker scripts
Timers scheduled to restart malware
Scripts under /tmp, /dev/shm, .config

How to Detect an SSH Compromise

1. Spike in Failed Logins

grep "Failed password" /var/log/auth.log | wc -l

If thousands → brute-force attack.

2. Successful Login from Unknown IP

Search for “Accepted”:

grep "Accepted" /var/log/auth.log

Check geolocation of IPs.

3. Logins at Strange Times

Example: 3 AM login on a server without scheduled admin work.

4. Root Login via SSH

If root login is allowed, this is a major red flag.

5. Unauthorized SSH Key Additions

Review authorized_keys modifications around compromise times.

6. Sudden SSH Configuration Changes

Changes to sshd_config without admin approval.

7. Malware Dropped After SSH Login

Look for files in:

/tmp/
/dev/shm/
/var/tmp/
Hidden folders like .cache, .local, .config

Tools for SSH Forensics

grep / awk / cut — log filtering
journalctl — systemd log analysis
last / lastb / who — login tracking
fail2ban logs — brute-force pattern detection
Logwatch / GoAccess — log summarization
OSSEC / Wazuh — intrusion detection
Volatility / memory forensics — SSH keys in memory

Signs of Successful SSH Compromise

Unknown successful login from foreign IP
New SSH keys added
New users created
Cron/systemd backdoors
Strange processes running
Deleted logs (rm -rf /var/log/*)
Commands executed in bash history
Suspicious outbound traffic
Data exfiltration traces (scp, rsync)

Summary

Investigating SSH compromise requires analyzing logs, login records, authorized keys, system configurations, bash history, and persistence mechanisms. SSH is a prime attack vector, and attackers often leave multiple traces: failed logins, suspicious successful logins, modified configurations, unauthorized keys, and persistence scripts. A thorough forensic investigation uncovers unauthorized access, determines the attack timeline, and identifies attacker actions on the system.

Mastering SSH forensics is essential in any Linux incident response or intrusion investigation.