Ephemera : Zero-Trust SSH-Zertifizierungsstelle

Ephemera ist eine leichtgewichtige, selbst gehostete SSH-Zertifizierungsstelle, die entwickelt wurde, um Zero-Trust-Zugriff für die Infrastruktur durchzusetzen. Es ersetzt statische SSH-Schlüssel durch kurzlebige Zertifikate, integriert hardwaregestütztes WebAuthn MFA und führt kryptografisch überprüfbare Audit-Trails.

[!NOTE] Kanonische Quelle: Codeberg
GitHub-Spiegel: GitHub (für Verfügbarkeit und Hosting)

Hochrangige Architektur

graph LR
    subgraph Client["User (Operator)"]
        SSH["SSH Client"]
        HW["Hardware Key<br/>WebAuthn / YubiKey"]
    end

    subgraph Auth["Authentication Boundary"]
        MFA["WebAuthn MFA<br/><i>Human presence required</i>"]
        OIDC["OIDC<br/><i>Optional</i>"]
    end

    subgraph CA["Ephemera SSH Certificate Authority"]
        CORE["Self-hosted CA<br/>Air-gap capable"]
        POLICY["Policy Engine<br/><i>Governance at issuance</i>"]
        BUDGET["Trust Budgeting<br/><i>Optional</i>"]
    end

    subgraph Targets["Target Servers"]
        NATIVE["Native OpenSSH<br/>TrustedUserCAKeys"]
        NOAGENT["No agents<br/>No SSH proxy"]
    end

    subgraph Audit["Audit & Recovery"]
        LOG["Tamper-Evident<br/>Audit Log"]
        BACKUP["Encrypted Backups<br/>Shamir Recovery"]
    end

    Client --> Auth
    Auth -->|"Short-lived cert"| CA
    CA -->|"Certificate expires<br/>automatically"| Targets
    CA -.->|"Post-fact integrity"| Audit

    style Auth fill:#e8f5e9,stroke:#2e7d32
    style CA fill:#e3f2fd,stroke:#1565c0
    style Audit fill:#fff3e0,stroke:#ef6c00

Was Ephemera tut: Regelt, wer Zugriff erhalten darf und wie lange.
Was Ephemera NICHT tut: Laufzeitüberwachung, MITM-Proxy, Befehlsinspektion.
Durchsetzung: Vollständig innerhalb von nativem OpenSSH — kein Ephemera-Agent auf Zielservern.
Schlüsselrotation: Nicht nötig — Zertifikate laufen automatisch ab.

Was Ephemera ist

Ephemera ist eine selbst gehostete SSH-Zertifizierungsstelle, die auf nativen OpenSSH-Funktionen aufbaut. Es ersetzt langlebige SSH-Schlüssel durch kurzlebige, Just-in-Time ausgestellte Zertifikate, mit expliziter physischer Anwesenheit und überprüfbarer Privilegieneskalation.

Es ist für Teams entwickelt, die eine zentrale SSH-Governance ohne MITM-Proxies, benutzerdefinierte Protokolle oder Cloud-Abhängigkeiten wünschen.

Was Ephemera nicht ist

• Kein SSH-Proxy oder MITM-Gateway
• Kein PAM-Ersatz
• Kein Laufzeitüberwachungs- oder Verhaltensanalysetool
• Kein Cloud-Dienst
• Keine SIEM- oder Erkennungsplattform

Projektstatus

Kernfunktionalität der SSH-CA: Produktionsreif
Trust Budgeting: Experimentell (Opt-in, Änderungen vorbehalten)

Die experimentellen Funktionen sind klar isoliert und standardmäßig deaktiviert.

Warum Ephemera?

Traditionelles SSH verlässt sich auf langlebige private Schlüssel, die über Laptops und Server verteilt sind. Sobald ein Schlüssel durchsickert, bleibt der Zugriff bestehen, bis Sie ihn entdecken und die Schlüssel überall austauschen. Ephemera ersetzt statische Schlüssel durch kurzlebige Zertifikate, die automatisch ablaufen, und verkleinert das Missbrauchsfenster von Monaten auf Minuten.

Positionierung

Am besten geeignet für

• Souveräne Bereitstellungen: Teams, die die vollständige Kontrolle über ihre CA ohne externe Cloud-Abhängigkeiten benötigen.
• Luftspalt-Umgebungen: Entwickelt, um nach der Bereitstellung ohne ausgehenden Internetzugriff zu arbeiten.
• Minimaler Overhead: Organisationen, die eine starke SSH-Sicherheit benötigen, ohne die Komplexität einer vollständigen Secrets-Plattform verwalten zu müssen.

Nicht geeignet für

• Unternehmens-IAM-Konsolidierung: Wenn Sie eine tiefe Integration mit komplexen AD/LDAP-Hierarchien benötigen, sind Teleport oder HashiCorp Vault besser geeignet.
• Managed-Service-Präferenz: Ephemera ist selbst gehostet und bietet keine SaaS-Variante an.

Hauptfunktionen

Just-in-Time-Zugriff: Zertifikate laufen in Minuten ab (Standard 5m), wodurch das Zeitfenster für gestohlene Anmeldedaten verkleinert wird.

WebAuthn-Durchsetzung: Die Zertifikatsausstellung erfordert physische MFA-Interaktion (FIDO2) über YubiKey oder TouchID.

Souveräne Wiederherstellung: Verschlüsselte Backups werden durch Shamir's Secret Sharing geschützt und erfordern ein Quorum zur Wiederherstellung.

Überprüfbares Audit: Alle CA-Aktionen werden in einem Merkle-verketteten Ledger protokolliert, um eine manipulationssichere Historie zu gewährleisten.

Granulares RBAC: Eine YAML-basierte Policy-Engine definiert den Zugriff basierend auf Rollen, Ressourcen und Bedingungen.

Experimentell: Trust Budgeting (Opt-in)

Ephemera enthält eine experimentelle, optionale Governance-Primitive namens Trust Budgeting.

Trust Budgeting begrenzt die kumulative privilegierte Autorität zum Zeitpunkt der Zertifikatsausstellung, indem Zugriff als endliche, sichtbare Ressource behandelt wird. Jede Zertifikatsausstellung verbraucht ein explizites Budget. Wenn das Budget aufgebraucht ist, wird die normale Ausstellung gestoppt, bis das Budget zurückgesetzt oder ein separater Notfallpfad (Break-Glass) verwendet wird.

Dieser Mechanismus:

• arbeitet nur zum Zeitpunkt der Zertifikatsausstellung
• führt keine Laufzeitüberwachung oder Agenten ein
• ist standardmäßig deaktiviert
• ist keine Sicherheitsgarantie

Trust Budgeting ist experimentell und kann sich ändern oder entfernt werden.

Dokumentation: docs/trust_budgeting.md

GateBridge: Schattenrichtlinienbewertung

Ephemera enthält GateBridge, ein Schattenbewertungssystem, das Richtlinienentscheidungen gegen eine alternative Engine (Gate0) validiert, ohne das Produktionsverhalten zu beeinflussen.

Garantien des Schattenmodus

• Fail-Open: Wenn Gate0 fehlschlägt, abstürzt oder eine Zeitüberschreitung auftritt, wird die Produktionsausstellung unbeeinträchtigt fortgesetzt.
• Keine Wiederholungen: Ein einzelner Versuch pro Bewertung – keine Wiederholungsschleifen.
• Keine Fallbacks: Die YAML-Richtlinienengine ist immer maßgeblich.
• Nur beobachtend: Gate0 blockiert oder modifiziert die Zertifikatsausstellung nie.

Log-Schema (policy-shadow.log)

Jeder Eintrag enthält:

Gesundheitsendpunkt

GET /api/admin/gate0/status

Returns:

{
  "bridge_version": "1.0.0",
  "gate0_version": "v0.2.1",
  "policy_hash": "sha256:8f4b...",
  "status": "healthy",
  "last_mismatch": null,
  "telemetry": {
    "latency_p50_ms": 2.3,
    "latency_p95_ms": 5.1,
    "latency_p99_ms": 8.7
  }
}

Rücknahme

GateBridge kann über ein Konfigurationsflag deaktiviert werden. Der Schattenmodus ist Fail-Open und hat keine Auswirkungen auf Autorisierungsentscheidungen.

Kompatibilität

Keine bahnbrechenden Änderungen an der Gate0-CLI-Schnittstelle. Schattenprotokolle erhalten neue Felder, bleiben aber abwärtskompatibel.

Schnellstart

Ziel: Stellen Sie Ihr erstes SSH-Zertifikat in unter 5 Minuten aus.

1. Ephemera starten

# Clone and start
git clone https://github.com/Qarait/ephemera.git
cd ephemera
docker compose up -d

Hinweis: Das CA-Masterpasswort wird automatisch generiert und beim ersten Start dauerhaft gespeichert.
Verwenden Sie für die Produktion CA_MASTER_PASSWORD in einer .env-Datei vor dem Start.

[!IMPORTANT] Produktionsbereitstellungen: Verwenden Sie das SoftHSM-Backend für hardwaregestützte Schlüsselisolation. Der private CA-Schlüssel wird niemals auf die Festplatte geschrieben. Siehe PKCS#11 Einrichtungsanleitung.

2. Auf das Dashboard zugreifen

Öffnen Sie http://localhost:3000 in Ihrem Browser.

Standard-Anmeldedaten:

• Benutzername: admin
• Passwort: Überprüfen Sie die Docker-Logs:
  root@kitploit:~

  docker compose logs ephemera | grep "Password:"
  

3. Ihr erstes Zertifikat ausstellen

1. Schließen Sie die WebAuthn-MFA-Einrichtung ab (erfordert Hardwareschlüssel oder TouchID)
2. Klicken Sie auf "Zertifikat anfordern"
3. Ihr Zertifikat ist 5 Minuten gültig

Alternative Compose-Dateien:

• docker-compose.dev.yml — Entwicklung mit lokalen Builds und Syslog
• docker-compose.test.yml — Enthält SSH-Ziel für End-to-End-Tests

2. Client-Einrichtung (Der Zauber)

# Install the CLI from source
git clone https://github.com/Qarait/ephemera.git
cd ephemera
pip install .

# Initialize your SSH config
ephemera init

# Login to the CA
ephemera login

# Issue your first certificate
ephemera renew

# Check your status
ephemera status

# Connect securely!
ssh user@your-server

Notfallwiederherstellung (Verschlüsseltes Backup)

Ephemera bietet einen sicheren Backup-Mechanismus, der Ihre kritischen Daten (CA-Schlüssel, Datenbank) mit einem zufälligen Passwort verschlüsselt und dieses Passwort dann in Shamir-Shards aufteilt. Dadurch wird sichergestellt, dass keine einzelne Person das Backup wiederherstellen kann, aber ein Quorum dazu in der Lage ist.

Backup erstellen

# Create encrypted backup and split password into 5 shards (threshold 3)
ephemera backup-create --k 3 --n 5 --out-dir ./backup

Dies erzeugt:

• ephemera_backup.enc (Das verschlüsselte Archiv)
• backup_shard_1_of_5.json, usw. (Die Passwort-Shards)

Hinweis: Bewahren Sie die Shards an getrennten, sicheren Orten auf. Bewahren Sie die verschlüsselte Backup-Datei sicher auf (sie ist ohne die Shards nutzlos).

Backup wiederherstellen

# Restore using the encrypted file and any 3 shards
ephemera backup-restore --backup ./backup/ephemera_backup.enc --shards ./backup/backup_shard_1_of_5.json ./backup/backup_shard_2_of_5.json ./backup/backup_shard_4_of_5.json --out-dir ./restored

Konfigurationsbeispiel (policy.yaml)

Ephemera verwendet eine leistungsstarke YAML-basierte Richtlinien-Engine für die rollenbasierte Zugriffskontrolle (RBAC).

# Define Roles
roles:
  developer:
    can_request_cert: true
    max_cert_duration: 300  # 5 minutes
    allowed_principals: ["dev-user"]
    
  admin:
    can_request_cert: true
    max_cert_duration: 3600 # 1 hour
    allowed_principals: ["root", "admin"]
    can_approve_sudo: true

# Define Rules
rules:
  # Developers can only access dev servers
  - role: developer
    resource: "dev-*"
    action: "ssh"
    effect: allow

  # Admins can access everything with MFA
  - role: admin
    resource: "*"
    action: "ssh"
    effect: allow
    conditions:
      mfa_required: true

Dokumentation

• Live-Dokumentationsübersicht
• Siehe ARCHITECTURE.md für Design-Details.
• Siehe SECURITY_MODEL.md für Bedrohungsannahmen und Vertrauensgrenzen.
• Siehe SECURITY_SPECIFICATIONS.md für tiefgehende technische Spezifikationen.
• Siehe PRODUCTION_READY.md für Härtungs- und Betriebs-Checklisten.
• Siehe docs/ für zusätzliche Anleitungen.

Sicherheit

Bitte beachten Sie SECURITY.md für Informationen zur verantwortungsvollen Offenlegung.

Möchten Sie beitragen? Schauen Sie sich unsere kleinen Aufgaben für neue Mitwirkende an.

[!TIP] Bedrohungsmodell und Sicherheitsannahmen sind hier dokumentiert. Feedback und Kritik sind willkommen.