# Every security event to your phone.

> Get a push on SSH logins, sudo use, and fail2ban bans. One curl from a login script sends the user, source IP, and rule to your phone in under a second.

<!-- source: https://pocketalert.app/use-cases/security-alerts -->

When something touches your server — an SSH login, a fail2ban ban, a CrowdSec or auditd rule — the user, source IP, and rule land on your phone in under a second. Know who logged in before they finish typing.

## Three steps to login alerts

1. **Get an API key** — Create an API key and a per-host application, then keep the key in an environment variable on the box.
2. **Hook the event** — Add a curl to your login script, fail2ban action, or IDS rule that posts the user and source IP.
3. **Watch your boxes** — Logins and bans hit your phone within a second. Put the event in the title so a root login from a new IP reads clearly apart from a routine deploy.

## From login to push

Wire any login, ban, or rule trigger to a single curl and the event reaches your phone as a push notification.

- **SSH login push** — A login script in /etc/profile.d or an sshrc curls Pocket Alert with the user and source IP on every interactive session.
- **fail2ban bans** — fail2ban runs a curl in its actionban, so each banned IP shows up on your phone with the jail that caught it.
- **sudo and admin logins** — A PAM hook or a sudo trigger fires when someone escalates, and a new admin login lands the same way.
- **IDS and audit triggers** — CrowdSec, Wazuh, OSSEC, and auditd shell out to curl on a rule match.
- **Field mapping** — GJSON field mapping pulls the user, source IP, and rule from a SIEM payload into the title and message.
- **Sub-second delivery** — Pushes land in well under a second, fast enough to catch a session while it is still open.

## Alert on every login

### 1. Get an API key

Create an application in Pocket Alert and copy your API key. Send it in the `Token` header. Give each host its own application so prod, bastion, and personal boxes stay on separate channels.

### 2. SSH login (sshrc or /etc/profile.d)

Drop a script in `/etc/profile.d` so every interactive login curls the messages API with the user and source IP from `$SSH_CONNECTION`:

```
# /etc/profile.d/pocketalert-login.sh
[ -n "$SSH_CONNECTION" ] && curl -s -X POST "https://api.pocketalert.app/v1/messages" \
  -H "Token: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"title\":\"SSH login\",\"message\":\"$USER from ${SSH_CONNECTION%% *} on $(hostname)\"}"
```

### 3. fail2ban ban (custom action)

Add an action in `/etc/fail2ban/action.d/pocketalert.conf` and reference it from a jail. fail2ban substitutes `<ip>` and `<name>` on each ban:

```
[Definition]
actionban = curl -s -X POST "https://api.pocketalert.app/v1/messages" \
  -H "Token: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"fail2ban: banned <ip>","level":"critical","message":"jail <name> banned <ip>"}'
```

### 4. SIEM (webhook)

For a SIEM or IDS that emits JSON (Wazuh, CrowdSec), create a webhook with a GJSON `message` template that maps its payload, then point the tool at the receive URL:

```
curl -X POST "https://api.pocketalert.app/v1/webhooks" \
  -H "Token: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Wazuh alerts","message":"%rule.description% from %data.srcip%","application_id":"qm47b9pzxzxg"}'
```

You get `https://p4a.me/wh/1234abcd` to paste into the tool's integration settings.

See the [webhook settings docs](https://info.pocketalert.app/api/webhooks/settings.html) for the messages API and GJSON field mapping.

## FAQ

### How do I get an alert on every SSH login?

Drop a small script in /etc/profile.d that curls Pocket Alert with $USER and the IP from $SSH_CONNECTION. Every interactive login then pushes to your phone.

### Can fail2ban send me a push?

fail2ban runs a curl in its actionban. Map the banned IP and jail into the message body, and you see each ban as it happens.

### How do I tell urgent logins from routine ones?

Put the event in the title so it reads at a glance: a root login from a new IP and a routine deploy-user login land as clearly different alerts. Give sensitive hosts their own application to keep them apart.

### Does this work with CrowdSec, Wazuh, or auditd?

Yes. CrowdSec, Wazuh, OSSEC, and auditd can all shell out to curl on a trigger. GJSON field mapping pulls the user, source IP, and rule into the title and message.

### How do I separate alerts per server?

Give each host its own application: prod, bastion, personal. Per-application channels keep the alerts separate so you know which box raised the flag. Pocket Alert relays the event; it is not an IDS.

### Can a root login break through silent mode at 3am?

Yes. Add "level":"critical" to the curl and Android posts it to a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. Keep routine deploy-user logins at level silent instead: no sound or vibration, but still in the history when you want the audit trail. On the free plan critical is delivered as high — still instant, just without the DND override.