How to Monitor & Secure SSH on Linux Server – Easy Guide

Monitoring and securing SSH on a Linux server means continuously watching SSH logs for suspicious activity, enforcing key-based authentication, restricting access with a firewall, and hardening sshd_config with best practices. Combine real-time protections (Fail2ban/CrowdSec), two-factor authentication, and regular patching to reduce brute-force attacks, account compromise, and misconfiguration risk.

If you manage Linux servers, learning how to monitor and secure SSH on a Linux server is non-negotiable. SSH is the default remote access method and a top target for automated bots. In this guide, I’ll show you how to harden sshd_config, set up real-time monitoring and alerts, and implement layered defenses—without locking yourself out.

What Threats Target SSH—and What to Watch

SSH faces constant brute-force attempts, credential stuffing, and privilege escalation attempts. Your defense starts with visibility. Know where to look and what “bad” looks like in your logs and metrics.

Key log signals

• Repeated “Failed password” or “Invalid user” entries from the same IP
• Logins at odd hours, from unfamiliar countries or networks
• Frequent disconnects at authentication (bot scans)
• Root login attempts and sudo authentication failures

Core metrics to track

• Authentication success/failure rates and spikes per IP
• Number of banned IPs (Fail2ban/CrowdSec)
• New public keys added, user changes, and sudoers edits
• SSH daemon restarts, configuration changes, and kernel updates

Quick SSH Security Checklist

• Use key-based authentication; disable passwords
• Disable direct root login
• Restrict users/groups allowed to SSH
• Enable Fail2ban or CrowdSec to block brute-force IPs
• Firewall: allow SSH only from trusted IPs where possible
• Set idle timeouts and lockout policies
• Enable 2FA (TOTP) for privileged accounts
• Monitor logs, enable alerts, and patch OpenSSH regularly

How to Monitor SSH Access in Real Time

Inspect SSH logs quickly

Most Debian/Ubuntu systems log to /var/log/auth.log, while RHEL/CentOS/AlmaLinux use /var/log/secure. With systemd, journalctl is often the fastest lens.

# See SSH activity today
sudo journalctl -u ssh -S today

# Tail SSH logs live (Debian/Ubuntu)
sudo tail -f /var/log/auth.log

# Tail SSH logs live (RHEL/CentOS/AlmaLinux)
sudo tail -f /var/log/secure

# Top failing IPs (Debian/Ubuntu)
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

# List recent successful and failed logins
last
lastb  # failed logins (requires btmp)

Block brute-force attacks with Fail2ban

Fail2ban reads your logs and bans offending IPs at the firewall automatically, a core component of SSH hardening.

# Install
# Debian/Ubuntu
sudo apt update && sudo apt install -y fail2ban
# RHEL/CentOS/AlmaLinux
sudo dnf install -y fail2ban

# Enable and start
sudo systemctl enable --now fail2ban

# Create jail override
sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = %(sshd_log)s
maxretry = 4
findtime = 10m
bantime  = 24h
ignoreip = 127.0.0.1/8 ::1
EOF

# Reload and check status
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Tip: Use ignoreip to whitelist your office/VPN. For cloud servers, combine with provider-level firewalls for defense-in-depth.

Audit SSH changes and logins with auditd

Use Linux Audit to track critical SSH events (config edits, daemon execs, auth changes).

# Install
sudo apt install -y auditd || sudo dnf install -y audit

# Watch sshd_config changes
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

# Track sshd execution (may vary by distro path)
sudo auditctl -a always,exit -F arch=b64 -S execve -F exe=/usr/sbin/sshd -k sshd_exec

# Query recent related events
sudo ausearch -k ssh_config
sudo ausearch -k sshd_exec | aureport -x --summary

For larger fleets, forward logs to a SIEM or a centralized stack (Elastic, Graylog, Wazuh) and set threshold alerts.

Harden sshd_config (Step-by-Step)

Back up and test safely

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
# Keep an existing SSH session open while reloading to avoid lockout
sudo sshd -t    # syntax check
sudo systemctl reload sshd

Recommended baseline options

These settings implement key-based auth, restrict accounts, reduce attack surface, and improve safety. Adjust for your distro and compliance policy.

# /etc/ssh/sshd_config (excerpt)
Protocol 2
# Optional: changing port reduces noise but is not a security control
# Port 22

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Restrict to known users or groups
AllowUsers deploy adminuser
# or
# AllowGroups sshusers

# Limit auth attempts and connection bursts
MaxAuthTries 3
MaxStartups 10:30:60
LoginGraceTime 20

# Disconnect idle sessions
ClientAliveInterval 300
ClientAliveCountMax 2

# Modern defaults in OpenSSH are secure; only pin ciphers if required
# Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
# MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Log more detail
LogLevel VERBOSE

# Banner to warn unauthorized users
Banner /etc/issue.net

After editing, validate with sshd -t and reload. Always test from a second terminal before closing your admin session.

Firewall and Rate Limiting

UFW (simple) or nftables/iptables (advanced)

# UFW example (Debian/Ubuntu)
sudo ufw allow 22/tcp
# or restrict to office/VPN
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable
sudo ufw status

# nftables example (policy-based)
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; }
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 ip saddr 203.0.113.0/24 accept
sudo nft add rule inet filter input tcp dport 22 drop

Pair your host firewall with cloud security groups. If you change the SSH port, remember to update rules accordingly.

CrowdSec vs. Fail2ban (quick comparison)

• Fail2ban: Lightweight, local bans, simple config, great for single servers.
• CrowdSec: Community-driven reputation feeds, distributed signals, rich scenarios; ideal for fleets.
• Both: Can integrate with iptables/nftables and export alerts.

Add 2FA (TOTP) to SSH

Two-factor authentication adds a one-time code (Time-based OTP) on top of your SSH key. This mitigates risks if a key or password is exposed. Apply to privileged users and break-glass accounts.

# Install Google Authenticator PAM module
# Debian/Ubuntu
sudo apt install -y libpam-google-authenticator
# RHEL/CentOS/AlmaLinux
sudo dnf install -y google-authenticator

# Per-user setup (run as each user)
google-authenticator -t -d -f -r 3 -R 30 -W

# Update PAM (common path; verify on your distro)
# Add this line near the top of /etc/pam.d/sshd:
# auth required pam_google_authenticator.so nullok

# Update sshd_config to allow keyboard-interactive for 2FA
KbdInteractiveAuthentication yes
# Keep PasswordAuthentication no for key+TOTP flow
AuthenticationMethods publickey,keyboard-interactive

sudo sshd -t && sudo systemctl reload sshd

Test with a secondary session before enforcing across all users. Store emergency scratch codes securely.

Set Up Alerts and Reports

Email summaries with Logwatch

# Install and configure
sudo apt install -y logwatch || sudo dnf install -y logwatch
# On systemd servers, create a daily timer or use cron
sudo logwatch --service sshd --range today --detail Med --mailto you@example.com

For real-time alerting, integrate Fail2ban with an action script to send notifications on bans/unbans, or forward logs to a SIEM with rules for spikes and anomalies.

Ongoing Maintenance and Compliance

• Patch OpenSSH and OS packages regularly; remove deprecated crypto configs as defaults evolve.
• Rotate and protect private keys; prefer hardware tokens for high-value access.
• Review users, groups, and authorized_keys monthly; remove stale access.
• Back up sshd_config and authorized_keys; document change history.
• Centralize logs; retain for at least 90 days to support forensics.

Common Mistakes and Safe Recovery

• Locking yourself out: Always keep one SSH session open while reloading; test from a second terminal.
• Over-tuning ciphers: Modern OpenSSH defaults are secure; pin algorithms only if your compliance policy demands it.
• Relying on port changes: Non-standard ports reduce noise but don’t replace authentication and monitoring.
• Ignoring egress: Attackers often exfiltrate data; monitor unusual outbound connections (use ss, nft, or a NIDS).

Why This Works: Layered, Practical Security

Across 12+ years hardening Linux servers, the most resilient SSH posture combines strong auth (keys + 2FA), minimal access (firewall + AllowUsers), active defense (Fail2ban/CrowdSec), and continuous visibility (logs + alerts). Each layer compensates for the others, cutting risk without harming uptime.

Need a Hand? Managed Hardening by YouStable

If you prefer expert setup, YouStable’s managed servers include SSH hardening, firewall tuning, proactive monitoring, and 24/7 support. We apply these best practices from day one and keep them aligned with evolving OpenSSH and Linux security standards.

FAQs: Monitoring & Securing SSH on Linux Server