79 lines
2.4 KiB
Markdown
79 lines
2.4 KiB
Markdown
---
|
|
project: ssh-login-alerting
|
|
type: project-plan
|
|
status: active
|
|
path: Tech/Projects
|
|
tags:
|
|
- pbs
|
|
- security
|
|
- ssh
|
|
- auditd
|
|
- n8n
|
|
- monitoring
|
|
created: 2026-04-19
|
|
updated: 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
|
|
|
|
- `pbsdeploy` SSH 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 |