I manage a server where several non-technical users still connect over SFTP with FileZilla, so password authentication remains enabled for their accounts. I already use fail2ban and a non-standard SSH port, and I'm working toward stronger options such as SSH keys and chrooted SFTP accounts.
What I'm missing is visibility: I'd like a push notification whenever someone successfully authenticates, including the username and source IP, so I can quickly distinguish normal activity from a suspicious login. I'm considering pam_exec with a webhook, monitoring auth.log or journald, or using a host-monitoring tool.
For incident response, what's the safest way to terminate a user's active sessions and prevent further access remotely? Do you use commands such as pkill -u and passwd -l, or have a phone-triggered workflow for that?
4 Answers
For a single server, a small journald or auth.log watcher is probably simpler than deploying a full monitoring stack. Have it match successful SSH or SFTP authentication events, then call a notification service with the username and source address. A pam_exec hook can work too, but log-based monitoring is usually easier to audit and less likely to interfere with authentication if the notification endpoint is unavailable.
Since the users connect from changing home and travel networks, IP allowlisting would be frustrating and unreliable. A better approach is to treat a new source address for a particular account as a higher-risk event rather than blocking every unfamiliar address. Keep a history of previously seen user/IP pairs and alert on changes, while still requiring strong passwords or, ideally, migrating those accounts to keys or restricted SFTP-only access.
Exactly. Their addresses change too often for a whitelist, but an unfamiliar address is still useful context for an alert and follow-up.
For emergency response, first identify the exact session and verify it is not a legitimate transfer. You can terminate the user’s processes with pkill -TERM -u username, followed by a stronger signal only if necessary, and disable the account with passwd -l or a suitable SSH access-control change. Also revoke or rotate credentials as appropriate. Put those actions behind a carefully restricted administrative script or approval workflow rather than exposing a raw phone-triggered shell command, and log every action.
fail2ban can run custom actions, but it is primarily designed to react to failed authentication and bans. It is not the best fit for notifying on every successful login. A lightweight host intrusion monitor such as OSSEC/Wazuh can watch authentication logs and trigger alerts, although that may be more software than you need for one machine. For a minimal setup, journald monitoring plus a notification script is easier to maintain.
That matches my experience: fail2ban is useful for blocking repeated failures, but successful-login notifications are better handled by a separate log watcher or security monitoring agent.
That sounds more practical than installing a complete monitoring platform just for login alerts. I’d also make sure the watcher queues or ignores notification failures so nobody gets locked out because a push provider is down.