Go beyond fail2ban and learn how to actively monitor SSH connections in real time. This guide covers everything from quick terminal commands for immediate insight to setting up robust, centralized logging for enterprise-grade security visibility.

Beyond Fail2Ban: Who’s Really Knocking on Your SSH Door?

I still remember the Tuesday morning from hell. Our main application monitoring dashboard lit up like a Christmas tree—CPU on `prod-web-03` was pegged at 100%. My first thought was a bad code push from the night before. My second was a runaway cron job. Both were wrong. After a frantic ten minutes, we discovered a junior engineer, in a rush to apply a hotfix, had accidentally set a security group rule to allow SSH from `0.0.0.0/0`. The internet had found our server, and thousands of bots were hammering `sshd`, trying to guess the root password. Sure, `fail2ban` was dutifully banning IPs, but it was like trying to empty the ocean with a bucket. We were completely blind to the sheer scale of the assault in real-time. That’s the day I mandated we get serious about *observing* SSH, not just reacting to it.

Why ‘tail -f’ and Fail2Ban Aren’t Enough

Look, I love `fail2ban`. It’s a fantastic, simple tool that does its job well. It’s the bouncer at the club door. But the bouncer only tells you who he’s kicked out; he doesn’t tell you about the suspicious crowd of 500 people gathering across the street, all trying the same locked side door. Relying only on reactive tools means you’re always a step behind. You’re missing the bigger picture: Are the attacks targeted? Is it a distributed botnet? Is a legitimate user’s key compromised? To answer these questions, you need real-time visibility.

So, let’s go through the playbook, from the quick-and-dirty fix to the full-blown enterprise solution we use here at TechResolve.

Solution 1: The “What’s Happening Right Now?” Quick Fix

You’re on a server, you suspect funny business, and you need eyes on `sshd` immediately. This is your go-to move. Forget `tail -f /var/log/auth.log`—the modern systemd journal is far more powerful.

On most modern Linux systems (Ubuntu 16.04+, CentOS 7+, etc.), you can use `journalctl` to follow the SSH service logs in real time. This is my favorite one-liner:

journalctl -f -u sshd -n 50

Let’s break that down:

• -f: “Follows” the log, just like `tail -f`. New entries will appear as they happen.
• -u sshd: Shows logs only for the `sshd` unit (on some systems like Debian/Ubuntu, it might be `ssh.service` or just `ssh`).
• -n 50: Shows the last 50 lines immediately so you have some context.

This will give you a clean, real-time stream of all SSH connection attempts, successes, and failures, without the noise from other system services. It’s perfect for quickly diagnosing an issue on a single machine.

Solution 2: The “Grown-Up” Centralized Logging Approach

The terminal trick is great for one server, but you’re not managing one server. You’re managing dozens, or hundreds. Hopping between SSH windows isn’t a scalable strategy. The real, permanent fix is to ship all your logs to one central place for analysis and alerting.

This is the core of observability. At TechResolve, we use a combination of tools to achieve this:

1. Log Shipper: An agent like `Filebeat` or `Promtail` is installed on every server. Its only job is to watch log files (like `/var/log/auth.log` or the systemd journal) and securely send new entries to a central server.
2. Log Aggregator/Database: A system like `Logstash` or `Loki` receives the logs, parses them (e.g., extracts the source IP, username, success/failure status), and stores them in a searchable database like `Elasticsearch`.
3. Visualization & Alerting: A tool like `Kibana` or `Grafana` sits on top of the database. This is where the magic happens. We build dashboards to visualize login attempts on a world map, chart failed logins over time, and create alerts for suspicious behavior.

With this setup, I can answer critical questions instantly: “Show me all failed SSH logins from outside the US in the last hour” or “Alert me if a user logs in from two different countries within 10 minutes.” This moves you from being reactive to proactive.

Pro Tip: Before you do anything else, disable password authentication and root login over SSH. Use SSH keys exclusively. This single change eliminates 99% of brute-force noise and is the single most important SSH security practice. Seriously, go do it now.

Solution 3: The “Paranoid CISO” Nuclear Option

Sometimes, you need to know more than just who logged in. You need to know *what they did*. This is where the built-in Linux Auditing System, `auditd`, comes in. This is less about watching the door and more about putting a camera and a microphone on everyone who walks through it.

Warning: `auditd` is incredibly powerful and can generate a massive volume of logs. Use it surgically.

You can create rules to log every command a specific user runs. For example, to watch all execution-related system calls for any user who authenticates via SSH, you can set up a rule that triggers on the `sshd` process. A simple rule might look something like this in your `/etc/audit/rules.d/audit.rules` file:

-a exit,always -F arch=b64 -F euid>=1000 -F euid!=unset -S execve -F auid!=-1 -k user_commands

This rule logs every command executed (`execve` syscall) by any user with a UID of 1000 or greater (i.e., normal users, not system daemons) who has a valid audit user ID (meaning they’re logged in). You can then search the audit logs for the `user_commands` key.

This is the tool you use when you need a forensic trail for compliance (PCI-DSS, SOC2) or after a security incident. It’s not for casual, real-time viewing, but it’s the ultimate source of truth when things go wrong.

Choosing Your Weapon

Here’s a quick cheat sheet to help you decide which approach fits your needs:

There’s no single “right” answer—it’s about layers. We use all three. `journalctl` for quick spot-checks, our Grafana dashboard for the daily overview, and `auditd` logs (shipped to our SIEM) for our security team’s deep-dive investigations. Start with what’s manageable and build from there. But please, stop flying blind.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions