---
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