How to Monitor and Audit SSH Sessions on Linux

Monitoring SSH access is not enough. Knowing who logged in does not tell you what they actually did. This guide explains how to monitor and audit SSH sessions on Linux, the limitations of default logs, and how to improve visibility and accountability.

Why SSH Auditing Matters

SSH provides direct access to production systems. Once a user is authenticated, they can modify files, run commands, install software, or exfiltrate data. Without auditing, these actions leave little to no trace.

SSH auditing is critical for:

• Incident response and forensic analysis
• Accountability in multi-user environments
• Compliance requirements (SOC 2, ISO 27001, HIPAA)
• Detecting misuse, accidents, or malicious activity

What Default SSH Logs Can (and Cannot) Tell You

Most Linux systems log SSH activity automatically, but these logs only cover authentication events—not session activity.

Common SSH log locations

• Debian / Ubuntu: /var/log/auth.log
• RHEL / CentOS / Rocky / Alma: /var/log/secure

# Debian / Ubuntu
sudo tail -n 200 /var/log/auth.log

# RHEL-based systems
sudo tail -n 200 /var/log/secure

These logs answer questions like:

• Who attempted to log in?
• From which IP address?
• Was the login successful or failed?

They do not answer:

• What commands were executed?
• What files were accessed or modified?
• How long the session lasted in detail

Basic Session Visibility Commands

Linux provides basic tools to inspect current and past logins. These are useful, but limited.

# Currently logged-in users
who

# Active sessions and load
w

# Login history
last

# Failed login attempts
lastb

These commands help answer who and when, but not what.

Auditing Commands with auditd

auditd allows you to monitor specific system calls and file access. It is powerful, but requires careful configuration.

Install auditd

# Debian / Ubuntu
sudo apt install auditd audispd-plugins

# RHEL-based
sudo dnf install audit audit-libs

Example: track execution of commands

# Log all command executions
sudo auditctl -a always,exit -F arch=b64 -S execve -k ssh_exec

You can then query events:

sudo ausearch -k ssh_exec

While powerful, auditd logs can be verbose and hard to interpret without centralized analysis.

TTY and Session-Level Logging

Another approach is to capture TTY input and output. This records what users type during SSH sessions.

PAM TTY auditing

sudo pam_tty_audit enable=username

This approach provides more detail but can:

• Generate large amounts of data
• Capture sensitive input
• Be difficult to replay coherently

Session Recording Tools

Some tools record full SSH sessions, including input and output, allowing replay similar to a video.

Common approaches include:

• Terminal I/O recording
• JSON-based command logging
• Time-indexed session replays

Session recording improves:

• Incident investigation
• Training and troubleshooting
• Compliance evidence

Centralizing SSH Audit Data

Reviewing logs on individual servers does not scale. Centralization is essential as infrastructure grows.

Common approaches include:

• Forwarding logs to a SIEM
• Central syslog servers
• Dedicated access auditing systems

Centralization allows correlation across servers, faster detection, and consistent retention policies.

Validate Your SSH Exposure

Auditing should be paired with external validation. Even well-configured servers can be accidentally exposed due to firewall or cloud security group changes.

You can verify whether your SSH port is reachable from the internet using this external tool:

https://www.singlejump.com/tools/

Checking exposure from outside your network helps confirm that access controls are working as expected.

Best Practices Summary

• Log authentication attempts and failures
• Understand the limits of default SSH logs
• Use auditd or TTY auditing where appropriate
• Record sessions for high-risk or privileged access
• Centralize logs for visibility and retention
• Regularly validate external SSH exposure

Final Thoughts

SSH auditing is not about surveillance—it is about accountability, security, and the ability to respond when something goes wrong.

If you cannot answer who did what, and when, then your SSH access is effectively unaudited.