SSHGuard on Debian and Ubuntu – installation, configuration and practical hardening

SSHGuard detects common brute-force attacks from log events and passes attackers to a firewall blocking backend. This guide covers installation, journald, nftables/iptables, whitelists, thresholds, IPv6, diagnostics and SSH hardening.

What SSHGuard does

SSHGuard is a detection and response layer, not a replacement for a firewall, strong authentication or patching. It watches logs, detects attack patterns and triggers blocking through the configured backend.

Installation on Debian

The package is named `sshguard`. After installation, inspect the actual configuration because the logging source and firewall backend can differ between releases.

sudo apt update
sudo apt install sshguard
sudo systemctl enable --now sshguard
systemctl status sshguard

Installation on Ubuntu

Ubuntu also provides `sshguard`. Start with `systemctl status sshguard` and inspect the journal after installation.

Input, parsers and blocking

SSHGuard needs a log source, matching parsers and a blocking backend. A running service alone does not prove that all three pieces work.

journald or log files?

Modern Debian and Ubuntu systems commonly use systemd-journald. Check where SSH failures actually appear with `journalctl -u ssh` or searches for `sshd`.

journalctl -u ssh
journalctl | grep -Ei 'sshd|ssh'

Firewall backend

Depending on the system, nftables, iptables or another backend may be involved. Avoid multiple competing blocking mechanisms without a clear ownership model.

nft list ruleset
iptables -S

Configuration

Thresholds, block duration, whitelist and service selection should be deliberate. The installed example configuration and man page are the most reliable references for the exact version.

Whitelist and recovery path

Blocking your own administration source can lock you out. Keep a second SSH session, VM console or out-of-band management path available before changes.

Thresholds

Aggressive values can block legitimate users; permissive values allow automated attacks to continue longer. Tune values using real logs and your environment.

Harden SSH separately

SSHGuard does not replace SSH hardening. Prefer keys, disable direct root login, restrict administrative users and keep OpenSSH current.

Test safely

First verify that SSHGuard sees events, then verify that the firewall backend creates a block. Test from a controlled network and keep a second access path open.

Diagnostics

Useful commands include `systemctl status sshguard`, `journalctl -u sshguard`, `journalctl -u ssh` and, depending on the firewall, `nft list ruleset` or `iptables -S`.

systemctl status sshguard
journalctl -u sshguard --no-pager
journalctl -u ssh --no-pager
nft list ruleset

SSHGuard versus Fail2ban

Both solve similar problems. Avoid configuring both to block the same service without a clear plan. For small servers, one primary log-based blocker is usually easier to operate.

IPv4 and IPv6

If SSH is reachable over IPv6, the blocking strategy must cover IPv6 too. `ss -lntp` and `ss -lntp6` help verify listeners.

ss -lntp | grep ':22'
ss -lntp6 | grep ':22'

Monitoring

Monitor SSHGuard itself as well as SSH. External monitoring verifies reachability; local logs show whether detection is working.

Practical baseline

Use SSHGuard as one layer beside key-based SSH, firewalling, updates, logging and monitoring. After changes: validate, reload, inspect logs and run a controlled test.

Conclusion

SSHGuard is small and focused. When input, parsers and the firewall backend are connected correctly, it can substantially reduce automated brute-force attacks.