2.4 KiB
2.4 KiB
| project | type | status | path | tags | created | updated | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ssh-login-alerting | project-plan | active | Tech/Projects |
|
2026-04-19 | 2026-04-19 |
SSH Login Alerting
Goal
Get notified in Google Chat the moment anyone SSHes into a PBS server.
Early warning system for compromised SSH keys or unauthorized access —
especially important now that pbsdeploy exists as a passphrase-less
key-based account.
Architecture
SSH login → auditd captures event → trigger script parses it →
curl POST to n8n webhook → n8n formats + sends to Google Chat
Design Decisions
- auditd over log-parsing — kernel-level event capture, more reliable
than tailing
/var/log/auth.log. - Shell script as middleman — dumb, single-purpose: parse auditd event, POST to n8n webhook. No logic in the script beyond formatting.
- n8n handles notification routing — keeps all alert formatting/delivery centralized where other PBS notifications already live. Server just fires events; n8n decides what to do with them.
- Alert on every login for v1 — simpler than trying to define "unexpected" up front. Tune later if noise becomes a problem.
- Scope: all accounts, all PBS servers — staging and production, every
user (
pbsdeploy, admin, root, etc.).
Why This Matters
pbsdeploySSH key has no passphrase. If it leaks, the attacker's first move is SSHing in.- Linode account is already behind 2FA, so LISH console access isn't the main threat vector.
- SSH is the primary attack surface — we need eyes on it.
Next Steps
- Configure auditd rules on staging server to capture SSH login events
- Write shell script that parses auditd events and POSTs to n8n webhook
- Build n8n workflow: webhook trigger → format message → send to Google Chat
- Test end-to-end on staging (SSH in, confirm alert arrives)
- Roll out to production
- Decide on Chat space (webadmin? dedicated security space?)
Open Questions
- Which Google Chat space should alerts go to?
- Do we want any metadata in the alert beyond username + source IP + timestamp (e.g., geolocation lookup on source IP)?
- Do we want a separate "critical" alert path for root logins?
Priority
Higher priority than env file hardening — it's a force multiplier. Even if the env hardening isn't done yet, knowing about an unauthorized login immediately limits blast radius.
...sent from Jenny & Travis