shelltrap.com
en de

Dokumentation

Lizenzierung und Aktivierung

Eine Lizenz je Server, offline gegen ein signiertes Token verifiziert. Der Lizenzdienst muss nicht erreichbar sein, damit der Scanner arbeitet — für die Erneuerung muss er es aber sein.

Die Bestandteile

BegriffBedeutung
LizenzschlüsselSTL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX — Crockford Base32, 25 Nutzzeichen einschließlich zweier Prüfzeichen. Wird bei der Erstellung der Lizenz erzeugt und genau einmal im Klartext zurückgegeben; der Dienst speichert nur sha256(key) sowie die ersten neun Zeichen als Anzeigepräfix.
LizenzDer Datensatz: Tarif, maximale Serveranzahl (standardmäßig 1), Status (active, suspended, terminated), Ablauf und die Verknüpfung mit Ihrem Konto.
AktivierungDie Bindung einer Lizenz an einen Server-Fingerabdruck. Höchstens max_servers gleichzeitig; deactivate gibt einen Platz frei.
Lizenz-TokenEin Ed25519-signiertes Dokument, das der Daemon offline verifiziert.
Server-Fingerabdrucksha256 über ein festes Präfix und den Inhalt von /etc/machine-id. Der Hostname wird nur zur Information übermittelt.

Aktivierung

shelltrap license activate STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
shelltrap license status
shelltrap license renew
shelltrap license deactivate

Das Token landet in /etc/shelltrap/license.token, Eigentümer root, Modus 0600. Der Schlüssel selbst wird nur als Präfix in /etc/shelltrap/license.key abgelegt, ebenfalls 0600, damit Sie ihn für Erneuerungen nicht erneut eingeben müssen. Wenn Sie den Schlüssel lieber gar nicht auf dem Server haben möchten, löschen Sie diese Datei und erneuern manuell.

Ein shelltrap-license.timer führt die Erneuerung täglich mit bis zu einer Stunde Jitter aus. Dieser Dienst ist eine vom Daemon getrennte systemd-Unit, weil er die einzige Komponente ist, die überhaupt AF_INET oder AF_INET6 benötigt — shelltrapd selbst ist auf AF_UNIX beschränkt.

root@web1 — /root
$ shelltrap license activate STL-7QK3M-P2VDA-XN94T-B6HRE-Z8SWF
plan             server
key prefix       STL-7QK3M
valid until      2027-09-04
token until      2026-10-04
fingerprint      e3b0c44298fc1c14…
servers          1 of 1
token written to /etc/shelltrap/license.token (0600, root)
$ shelltrap --json health
{"status":"ok","watcher_tier":"A","scanner_workers":2,"clamd":"ok",
 "ruleset_gen":"20260903T120000Z-0001","policy_gen":17,"queue_age_s":0,
 "overflows":0,"feeds":"ok"}

Aktivierung, anschließend eine Health-Prüfung. Gezeigt werden die Felder, die die CLI dokumentiert: Tarif, Präfix, Gültigkeit, Token-Gültigkeit, Fingerabdruck und Server-Kontingent.

Was im Token steht

Die Nutzlast ist kanonisches JSON mit sortierten Schlüsseln. Die betrieblich wichtigen Felder:

  • not_after — Gültigkeit des Tokens, 30 Tage nach der Ausstellung. Danach ist das Token ungültig, selbst wenn die Lizenz selbst länger läuft. Das ist es, was die Erneuerung erzwingt.
  • license_expires_at — bezahlt bis, zuzüglich 14 Tagen Kulanzfrist. Liegt dieses Datum vor not_after, gilt das frühere Datum.
  • fingerprint — der Server, für den dieses Token gilt. Ein auf eine andere Maschine verschobenes Token funktioniert nicht.
  • features — die Liste der Funktionen, die die Lizenz freischaltet.
  • key_id — gegen welchen Signaturschlüssel zu prüfen ist.

Die Verifikation nutzt gepinnte öffentliche Lizenzschlüssel. Das Paket liefert den öffentlichen Panomity-Lizenzschlüssel unter /usr/share/shelltrap/keys/license-panomity.pub aus, und die Konfiguration darf Schlüssel nur ergänzen, dieses Pinning aber nie ersetzen. Das ist Absicht: Es hindert einen Serverbetreiber daran, den Vertrauensanker auszutauschen.

Die drei Zustände

ZustandWannWas der Daemon tut
licensedgültiges Token, passender Fingerabdrucknormaler Betrieb
graceToken läuft in weniger als 7 Tagen ab und die Erneuerung schlägt fehlnormaler Betrieb, dazu eine Warnung im Log, Health degraded mit license_renewal_failed und eine Administratorbenachrichtigung pro Tag
unlicensedkein Token, ungültige Signatur, Ablauf überschritten oder fremder Fingerabdrucksiehe unten

Im Zustand unlicensed stürzt der Daemon nicht ab und läuft nicht in eine Neustartschleife:

  • der Watcher läuft weiter, Ereignisse werden gezählt, aber nicht gescannt,
  • der Scheduler plant nichts,
  • das Upload-Gate antwortet mit allow und dem Grund unlicensed,
  • Health meldet status: "unlicensed" mit einem präzisen degraded_reasons-Eintrag — license_missing, license_expired, license_invalid oder license_fingerprint_mismatch,
  • ein Audit-Eintrag license.state wird geschrieben,
  • die Metriken shelltrap_license_state{state=…} und shelltrap_license_expires_seconds bilden das ab,
  • der Feed-Dienst antwortet mit 401, und der Feed-Controller meldet feeds: unlicensed.

Das Entwurfsziel dahinter sei ausdrücklich genannt: Eine abgelaufene Lizenz muss laut nutzlos sein, niemals leise gefährlich. Ein Gate, das Uploads abzuweisen beginnt, weil eine Rechnung überfällig ist, wäre ein schlechteres Produkt als eines, das dies in Health meldet und den Verkehr durchlässt.

Feeds und die Lizenz

Jeder Feed-Abruf sendet das kompakte Token als Bearer-Credential. Ohne gültiges Token antwortet der Dienst mit 401. Signaturen, Updates und Support sind die kommerzielle Grenze dieses Produkts — unter Signatur-Feeds steht, was ankommt, wenn das Token gültig ist.

Downloads

GET /v1/downloads/index.json ist ohne Lizenz lesbar, damit eine Website die aktuellen Versionen anzeigen kann. Die Pakete selbst werden nur gegen eine aktive Lizenz ausgeliefert: GET /v1/downloads/<file>?key=STL-…. Der Dienst protokolliert das Schlüsselpräfix, nie den Schlüssel. Es gibt keine unauthentifizierten Paketlinks; deshalb hat die Download-Seite ein Formular statt einer Liste von URLs.

Eine Lizenz auf einen anderen Server umziehen

# auf der alten Maschine
shelltrap license deactivate
# auf der neuen Maschine
shelltrap license activate STL-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Die erneute Aktivierung eines bereits aktiven Fingerabdrucks stellt lediglich ein neues Token aus und verbraucht keinen zweiten Platz; eine Erneuerung sperrt Sie also nie aus Ihrem eigenen Server aus.

Was eine Lizenzprüfung nicht leisten kann

Ein Angreifer mit Root-Rechten auf Ihrem Server kann jedes Binary darauf patchen, unseres eingeschlossen, und keine clientseitige Prüfung übersteht das. Das schreiben wir auch in den Lizenzbedingungen . Der kommerzielle Schutz beruht darauf, dass Signaturen, Updates und Support nur mit einer aktiven Lizenz erreichbar sind und dass kein Quellcode ausgeliefert wird.

Weiter

Gekürzt aus dem Shelltrap-Lizenzierungshandbuch, Revision 2026-09-04.