Kommandozeile und SSH-Agent.

Wie installiert man das CLI?

Das Kommandozeilen-Tool ist ein Programm aus einer einzigen Datei für macOS (Apple Silicon und Intel) und Linux (x64 und arm64); Node.js wird nicht benötigt. Am einfachsten geht es mit Homebrew:

brew install keyzula/tap/keyzula
keyzula --version

Auf Linux-Rechnern ohne Homebrew (etwa Servern und CI-Runnern) laden Sie das Programm herunter und entpacken es nach /usr/local/bin:

# x64
curl -fsSL https://github.com/KeyZula/homebrew-tap/releases/download/v1.2.1/keyzula-1.2.1-linux-x64.tar.gz | sudo tar -xz -C /usr/local/bin keyzula
# arm64
curl -fsSL https://github.com/KeyZula/homebrew-tap/releases/download/v1.2.1/keyzula-1.2.1-linux-arm64.tar.gz | sudo tar -xz -C /usr/local/bin keyzula

Unter Windows (x64) laden Sie keyzula.exe mit PowerShell herunter und fügen es zum PATH hinzu (danach ein neues Terminal öffnen):

$dir = "$env:LOCALAPPDATA\Programs\KeyZula"
Invoke-WebRequest https://github.com/KeyZula/homebrew-tap/releases/download/v1.2.1/keyzula-1.2.1-windows-x64.zip -OutFile "$env:TEMP\keyzula.zip"
Expand-Archive -Force "$env:TEMP\keyzula.zip" $dir
[Environment]::SetEnvironmentVariable("Path", [Environment]::GetEnvironmentVariable("Path", "User") + ";$dir", "User")

Aktualisieren:

brew update && brew upgrade keyzula

Die Archive und eine SHA256SUMS-Datei werden in den Releases von homebrew-tap veröffentlicht.

Anmeldung und Grundlagen

keyzula login fragt nach Ihrer E-Mail-Adresse und Ihrem Master-Passwort und, falls die Zwei-Schritt-Anmeldung aktiv ist, nach einem Code. Das Master-Passwort wird bei der Eingabe nicht angezeigt und nie auf die Festplatte geschrieben.

keyzula login
keyzula status
keyzula list github
keyzula get password GitHub
keyzula get username GitHub
keyzula get totp GitHub

get gibt das Feld password, username oder totp eines Eintrags nach Name oder ID aus; 2FA-Codes werden auf Ihrem Rechner berechnet. list und status bieten mit --json eine Ausgabe für Skripte. Läuft der SSH-Agent entsperrt, fragen diese Befehle nicht nach dem Passwort.

Standardserver ist https://app.keyzula.com. Für einen anderen Server nutzen Sie die Option --server oder die Umgebungsvariable KEYZULA_SERVER:

keyzula login --server https://vault.example.com

Konten mit SSO- oder passwortloser Anmeldung (vertrauenswürdige Geräte) werden in der Kommandozeile noch nicht unterstützt.

Wie startet man den SSH-Agent?

Der integrierte SSH-Agent stellt die SSH-Schlüssel-Einträge aus Ihrem persönlichen Tresor und aus den Sammlungen, auf die Sie Zugriff haben, für ssh und git bereit. Private Schlüssel liegen nur im Arbeitsspeicher des Agent-Prozesses, landen nie auf der Festplatte und werden beim Sperren gelöscht.

keyzula ssh-agent --daemon
keyzula ssh add-config

--daemon startet den Agent im Hintergrund (Protokoll: ~/.config/keyzula/ssh-agent.log; es enthält nur Schlüsselnamen, Fingerabdrücke und Zeiten). Der Agent aktualisiert den Tresor alle 5 Minuten, neue Schlüssel erscheinen also von selbst.

• Unterstützte Schlüssel: Ed25519, RSA (rsa-sha2-256/512) und ECDSA P-256/384/521; OpenSSH- und PEM/PKCS#8-Format, auch passwortgeschützte Schlüssel (das Feld für die Schlüssel-Passphrase im Eintrag wird verwendet).
• Hardware-Schlüssel (sk-*) und DSA werden nicht unterstützt.
• Mit der Berechtigung „Passwort nicht sehen“ geteilte Schlüssel werden nicht in den Agent geladen.
• Hinzufügen und Entfernen über ssh-add wird abgelehnt; verwalten Sie Schlüssel im Tresor.

ssh-Konfiguration

keyzula ssh add-config gibt den passenden Konfigurationsausschnitt für Ihr System aus. Um die Schlüssel aus Ihrem Tresor für alle Hosts zu nutzen, fügen Sie ihn in ~/.ssh/config ein:

# ~/.ssh/config
Host *
  IdentityAgent "~/.config/keyzula/ssh-agent.sock"

Nur für die aktuelle Terminal-Sitzung nutzen Sie die Variable SSH_AUTH_SOCK:

export SSH_AUTH_SOCK="$HOME/.config/keyzula/ssh-agent.sock"
ssh-add -L
ssh -T git@github.com

Unter macOS und Linux wird der Socket mit Berechtigungen angelegt, die nur Ihnen Zugriff erlauben (0600). Ist XDG_CONFIG_HOME gesetzt, ändert sich der Pfad entsprechend; ssh add-config zeigt immer den richtigen.

Unter Windows nutzt der Agent statt eines Sockets eine Named Pipe mit einem für Ihren Benutzer eindeutigen Namen und arbeitet mit dem in Windows integrierten OpenSSH-Client. Fügen Sie die IdentityAgent-Zeile aus ssh add-config in %USERPROFILE%\.ssh\config ein. Git for Windows bringt ein eigenes ssh mit; leiten Sie Git daher auf das von Windows um. Die Befehle zum Signieren von Commits zeigt ssh add-config ebenfalls:

keyzula ssh-agent --daemon
keyzula ssh add-config
git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

Signaturbestätigung und automatische Sperre

keyzula ssh-agent --confirm
keyzula ssh-agent --daemon --lock-after 2h
keyzula lock
keyzula unlock

• --confirm: fragt vor jeder Signatur im Terminal des Agents nach einer Bestätigung. Da dafür ein Terminal nötig ist, lässt es sich nicht mit --daemon kombinieren; starten Sie den Agent im Vordergrund in einem eigenen Terminal-Tab.
• --lock-after: sperrt den Agent nach so viel Inaktivität (Standard 12h; 0 = nie). Dauern schreiben Sie etwa als 30m oder 2h.
• keyzula lock löscht die Schlüssel aus dem Speicher; keyzula unlock fragt nach Ihrem Master-Passwort und entsperrt den Agent wieder.

Wie signiert man Git-Commits?

Sie können Git-Commits mit einem SSH-Schlüssel aus Ihrem Tresor signieren. Bei laufendem Agent:

git config --global gpg.format ssh
git config --global user.signingkey "key::$(ssh-add -L | head -n1)"
git config --global commit.gpgsign true

ssh-add -L listet die öffentlichen Schlüssel im Agent; bei mehreren Schlüsseln wählen Sie statt head -n1 die richtige Zeile. Hinterlegen Sie denselben öffentlichen Schlüssel in GitHub oder GitLab als Signaturschlüssel.

Geheimnisse: read, run und inject

Statt Passwörter in Skripte und Konfigurationsdateien zu schreiben, schreiben Sie eine Referenz auf den Wert in Ihrem Tresor:

kz://<collection>/<item>/<field>

• Sammlung und Eintrag: Name (ohne Beachtung der Groß-/Kleinschreibung) oder ID. ~ ist Ihr persönlicher Tresor (nur für angemeldete Nutzer).
• Feld: password, username, totp (aktueller Code), notes, url, private_key, public_key, passphrase, number, code oder die Bezeichnung eines eigenen Felds.
• Schreiben Sie ein / in einem Namen als %2F und setzen Sie Referenzen in der Shell immer in Anführungszeichen.

keyzula read "kz://Production/Postgres/password"
keyzula read -n "kz://~/GitHub/totp"

Der Befehl run löst die kz://-Werte in der Umgebung und in den mit --env-file angegebenen Dateien auf und startet den Befehl mit dieser Umgebung. Aufgelöste Werte werden in der Ausgabe des Befehls standardmäßig verborgen; für interaktive Programme nutzen Sie --no-masking.

# .env
DB_PASSWORD=kz://Production/Postgres/password
STRIPE_KEY="kz://Production/Stripe/API key"

keyzula run --env-file .env -- ./deploy.sh

Der Befehl inject füllt die Platzhalter {{ kz://… }} in einer Vorlage aus. Die Ausgabedatei wird mit Berechtigungen geschrieben, die nur Ihnen das Lesen erlauben (0600); eine vorhandene Datei wird nur mit --force ersetzt.

# config.yml.tpl
database:
  password: "{{ kz://Production/Postgres/password }}"

keyzula inject -i config.yml.tpl -o config.yml

Alle Referenzen werden aufgelöst, bevor etwas startet; schlägt auch nur eine fehl, wird nichts gestartet oder geschrieben.

Wofür sind Dienstkonten da?

Ein Dienstkonto ist eine Maschinenidentität, mit der Server, CI-Jobs und KI-Agenten die Geheimnisse in ausgewählten Sammlungen einer Organisation lesen – nur lesend. Inhaber oder Administratoren legen es im Web-Tresor unter Organisation → Dienstkonten an, wählen die Sammlungen und erzeugen ein Zugriffstoken. Das Token wird nur einmal angezeigt.

export KEYZULA_SERVICE_TOKEN='kzsa_1_…'
keyzula read "kz://Production/Postgres/password"

• Zero Knowledge: Token und Schlüssel entstehen im Browser des Administrators. Der Server sieht das Token selbst nie; das Kommandozeilen-Tool entschlüsselt Einträge lokal.
• Nur lesend: Ein Dienstkonto kann nur die ihm zugewiesenen Sammlungen lesen; es kann keine Einträge anlegen oder ändern.
• Widerruf: Jedes Token lässt sich einzeln widerrufen und kann ein Ablaufdatum haben. Beim Widerruf werden seine Schlüssel vom Server gelöscht.
• Audit: Jeder Lesezugriff wird mit Zeit, IP-Adresse und Sammlung im Audit-Protokoll der Organisation festgehalten.

Ohne KEYZULA_SERVICE_TOKEN laufen dieselben Befehle als angemeldeter Nutzer.

Beispiel für GitHub Actions

Hinterlegen Sie das Token in den Secrets Ihres Repositorys als KEYZULA_SERVICE_TOKEN. Laden Sie im Workflow die Linux-Version herunter und übergeben Sie Geheimnisse als kz://-Referenzen in der Umgebung eines Schritts:

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      KEYZULA_SERVICE_TOKEN: ${{ secrets.KEYZULA_SERVICE_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - name: Install KeyZula CLI
        run: curl -fsSL https://github.com/KeyZula/homebrew-tap/releases/download/v1.2.1/keyzula-1.2.1-linux-x64.tar.gz | sudo tar -xz -C /usr/local/bin keyzula
      - name: Deploy
        env:
          DB_PASSWORD: kz://Production/Postgres/password
        run: keyzula run -- ./scripts/deploy.sh
      - name: Render config
        run: keyzula inject -i deploy/app.yml.tpl -o deploy/app.yml

Der Befehl run entfernt KEYZULA_SERVICE_TOKEN aus der Umgebung des Kindprozesses, leitet Signale weiter und gibt den Exit-Code unverändert zurück. Nutzen Sie ein Token pro Repository oder Umgebung, geben Sie ihm ein Ablaufdatum und widerrufen Sie es, sobald es nicht mehr gebraucht wird.

Geben Sie auch KI-Agenten ein eigenes Dienstkonto, das nur die benötigte Sammlung sieht. API-Schlüssel gelangen dann nur in die Prozessumgebung, nie in den Prompt oder ins Repository:

KEYZULA_SERVICE_TOKEN=kzsa_1_… \
OPENAI_API_KEY="kz://AI agents/OpenAI/API key" \
keyzula run -- python agent.py

KI-Assistenten (MCP)

keyzula mcp verbindet Claude, Cursor, VS Code und andere MCP-fähige KI-Assistenten mit Ihrem Tresor. Der Assistent findet Einträge über Name, Website oder Benutzernamen und nutzt Geheimnisse über kz://-Referenzen, ohne sie zu sehen: Die Werte landen in der Umgebung eines Befehls, den er ausführt (in der Ausgabe verborgen), oder in einer Datei, die nur Sie lesen können.

keyzula login
keyzula ssh-agent --daemon
claude mcp add keyzula -- keyzula mcp

Für Claude Desktop, Cursor und andere Clients tragen Sie ihn in die MCP-Konfiguration ein. Desktop-Apps sehen den PATH Ihres Terminals oft nicht; nutzen Sie den vollständigen Pfad aus which keyzula. Die Einrichtung für jeden Assistenten Schritt für Schritt finden Sie auf der Seite KI-Assistenten.

{
  "mcpServers": {
    "keyzula": { "command": "/opt/homebrew/bin/keyzula", "args": ["mcp"] }
  }
}

• search_items liefert Namen, Orte, Benutzernamen, Websites und Referenzen, niemals Passwörter.
• run_command startet ein Programm mit den Geheimnissen in seiner Umgebung und gibt die Ausgabe mit verborgenen Werten zurück.
• inject_template füllt eine {{ kz://… }}-Vorlage und schreibt eine Datei, die nur Sie lesen können (0600); an den Assistenten geht nur der Dateipfad.
• read_secret, das einen Wert wie ein Passwort oder einen 2FA-Code anzeigt, ist standardmäßig aus. Mit --allow-reveal wartet jede Anfrage auf Ihre Bestätigung in einem KeyZula-Fenster auf Ihrem Computer, das der Assistent nicht anklicken kann.

Der MCP-Server liest nur aus dem entsperrten Agenten und fragt nie nach Ihrem Master-Passwort. Mit --confirm fragt er vor jeder Nutzung eines Geheimnisses. Jede Nutzung erscheint im Zugriffsprotokoll als "Von KI-Assistent verwendet". Für Teams starten Sie ihn mit einem Dienstkonto-Token, damit der Assistent nur die gewählten Sammlungen sieht.

Sicherheitshinweise

• In ~/.config/keyzula (0700) werden nur Server-Adresse, E-Mail, Sitzungstoken und die vom Server gelieferten verschlüsselten Schlüssel gespeichert (config.json, 0600).
• Master-Passwort, abgeleitete Schlüssel, der entschlüsselte Tresor und private SSH-Schlüssel landen nie auf der Festplatte; sie liegen nur im Arbeitsspeicher des Agent-Prozesses und werden beim Sperren gelöscht.
• Mit einem Dienst-Token schreibt das Tool nichts in sein Konfigurationsverzeichnis. Außer der ausdrücklich angeforderten inject -o-Ausgabe wird kein Geheimnis auf die Festplatte geschrieben.
• Abrufe mit get und die vom Agent zum Signieren genutzten Schlüssel werden wie in den anderen Apps im Zugriffsprotokoll erfasst (nur ID des Eintrags, Aktion und Zeit; nie Name oder Inhalt).
• Legen Sie das Token nie in einem Repository, einem Docker-Image oder einem Prompt ab; bewahren Sie es in den Secrets Ihres CI auf.

Details zur Architektur finden Sie auf der Seite Sicherheit.

Häufige Fragen

Auf welchen Systemen läuft das Kommandozeilen-Tool?

Es ist ein Programm aus einer einzigen Datei für macOS (Apple Silicon, Intel) sowie Linux (x64, arm64); Node.js wird nicht benötigt. Am einfachsten installieren Sie es mit Homebrew. Unter Windows (x64) ist es eine einzelne Datei keyzula.exe.

Werden meine SSH-Schlüssel auf die Festplatte geschrieben?

Nein. Private Schlüssel liegen nur im Arbeitsspeicher des Agent-Prozesses; beim Sperren werden sie gelöscht. Im Konfigurationsverzeichnis landen nur Server-Adresse, E-Mail, Sitzungstoken sowie die vom Server gelieferten verschlüsselten Schlüssel.

Welche SSH-Schlüsseltypen werden unterstützt?

Ed25519, RSA (rsa-sha2-256/512) sowie ECDSA P-256/384/521 im OpenSSH- oder PEM/PKCS#8-Format, auch mit Passphrase. Hardware-Schlüssel (sk-*) oder DSA werden nicht unterstützt.

Wie gebe ich Geheimnisse an CI oder KI-Agenten weiter?

Erstellen Sie im Web-Tresor ein Dienstkonto, wählen Sie nur die nötigen Sammlungen aus und hinterlegen Sie das Zugriffstoken in den Secrets Ihres CI. Der Befehl run löst kz://-Referenzen erst zur Laufzeit auf; die Werte landen weder im Repository noch in einem Prompt.

Können KI-Assistenten wie Claude oder Cursor meinen Tresor nutzen?

Ja, über den Server keyzula mcp. Der Assistent durchsucht Ihre Einträge und nutzt Geheimnisse über kz://-Referenzen, ohne sie zu sehen. Das Anzeigen eines Werts ist standardmäßig aus und erfordert, wenn eingeschaltet, Ihre Bestätigung für jede Anfrage. Jede Nutzung wird im Zugriffsprotokoll festgehalten.

Können Konten mit SSO-Anmeldung die Kommandozeile nutzen?

Noch nicht: Konten, die sich per SSO oder passwortlos (vertrauenswürdiges Gerät) anmelden, werden in der Kommandozeile nicht unterstützt. Für Server oder CI nutzen Sie ein Dienstkonto Ihrer Organisation.