sentinellGitHub

● self-hosted / open source

Every SSH attack on your server, explained.

Sentinell reads sshd logs, groups attempts into incidents, alerts you on Telegram, and writes a report that cites the exact log lines.

Download source

Or paste a setup prompt into your agent

See the dashboard
ubuntu-01:8080
Sentinell incident list with five correlated SSH incidents

  1. 01Incidents

    Every attempt, grouped.

    Failures from one address become one incident with a severity, the patterns it matched and how many usernames it tried. One Telegram message, not a wall of log lines.

    ubuntu-01:8080
    Sentinell incident list with five correlated SSH incidents

  2. 02Investigation

    A report that shows its work.

    Each finding is marked observed, suspected or unknown and links the event IDs it relies on. Claims that cite events that don't exist are thrown out before you see them.

    ubuntu-01:8080
    Sentinell investigation with observed, suspected and unknown findings citing event IDs

  3. 03Response

    You decide what gets blocked.

    Sentinell proposes a temporary nftables block with an expiry. Nothing runs until you approve it, and allowlisted addresses are refused even then.

    ubuntu-01:8080
    Sentinell response panel with a temporary IP block awaiting approval

  4. 04Setup

    Set up from the dashboard.

    Each step checks itself off when the host reports it working: password, model key, Telegram, collector and the optional block runner.

    ubuntu-01:8080
    Sentinell setup checklist with three of five steps done

05MCP

Ask your agent what happened.

Sentinell ships a read-only MCP server. Claude, Cursor or Grok Bot can list incidents, read the investigation and pull the evidence, and every answer comes back with the event IDs behind it.

  • list_incidents
  • get_incident
  • get_investigation
  • get_incident_events
  • get_auth_history
  • list_alerts
  • get_host_metadata
  • health
agent · sentinell mcp

  1. › What hit ubuntu-01 in the last day?

  2. ●list_incidents{ "since": "24h" }→ 5 incidents

  3. ●get_investigation{ "id": "inc-001" }→ 2 observed · 1 suspected · 1 unknown

  4. 203.0.113.7 tried 7 usernames in 100 seconds, then logged in as demo 30 seconds after the last failure. That is suspicious, not confirmed: auth logs don't show what happened after login. A temporary block is waiting for your approval in the dashboard.

    bc7a7e9b487fd82d2c8eb6a3

Managed from the agent

Your agent runs the sentinell CLI on the host to start the server and hand out access. Nothing about it needs the dashboard except the password.

Guardrails. MCP stays locked until the dashboard password exists. No tool can block an IP, approve an action or read an API key. Those stay with you.

  • $ sentinell mcpLocal server for agents on the same host.
  • $ sentinell mcp token create --name grokRemote access for cloud agents. Printed once, stored hashed.
  • $ sentinell mcp token listSee which agents have access.
  • $ sentinell mcp token revoke <id>Cut one off without touching the rest.
  • $ sentinell statusPipeline health, no secrets.

Run it on your server.

One command. Bring your own model key, or none at all.