I manage a server where several nontechnical users still upload files over SFTP with FileZilla, so password authentication remains enabled for their accounts for now. Moving them to keys and tighter chrooted accounts is on my list, and fail2ban plus a nonstandard SSH port are already configured.
What I'm missing is immediate visibility when someone successfully authenticates. I'd like a push notification containing the username and source IP so I can quickly distinguish a normal login from something suspicious. I'm considering pam_exec with a webhook, watching auth.log or journald, or using a lightweight monitoring agent.
For incident response, what's the safest way to terminate a user's existing sessions and disable the account remotely? Do you use commands such as pkill -u and passwd -l, or have a phone-triggered workflow for that?
3 Answers
fail2ban can run custom actions, but it is primarily designed around detecting failed authentication and banning offenders. A successful-login notification is outside its main use case, so a log watcher, audit tool, or lightweight host intrusion-monitoring agent may fit better. For one box, I’d avoid installing a large platform unless you also need file-integrity checks and broader security monitoring.
For emergency response, use a restricted administrative action rather than exposing arbitrary shell commands through a phone automation. The action can terminate the user’s processes and sessions, lock the account, and optionally disable the relevant SSH key or SFTP access. Test the sequence carefully so it cannot lock out your own administrative account, and keep an audit trail of who triggered it. Also remember that terminating processes may not immediately remove every existing network connection, so verify the session is actually gone afterward.
For a single server, a small journald or auth.log watcher that triggers a notification webhook is probably simpler than deploying a complete monitoring stack. Send alerts for successful SSH or SFTP authentication and include the account, source address, and timestamp. You can also keep a per-user history of previously seen addresses and alert more loudly when a new one appears. IP allowlisting is usually impractical for people who work from changing home and mobile networks.
That seems like the right balance. A new-address alert is more useful here than blocking unfamiliar addresses, since the users travel and their normal IPs change regularly.
That was my concern with using fail2ban for this. It can be extended, but a dedicated success-event watcher makes the intent clearer and should be easier to maintain.