diff --git a/Tech/Projects/ssh-login-alerting.md b/Tech/Projects/ssh-login-alerting.md
new file mode 100644
index 0000000..40f91ab
--- /dev/null
+++ b/Tech/Projects/ssh-login-alerting.md
@@ -0,0 +1,79 @@
+---
+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
\ No newline at end of file