Installation
Das KeyZula-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 --versionAuf 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.1.0/keyzula-1.1.0-linux-x64.tar.gz | sudo tar -xz -C /usr/local/bin keyzula
# arm64
curl -fsSL https://github.com/KeyZula/homebrew-tap/releases/download/v1.1.0/keyzula-1.1.0-linux-arm64.tar.gz | sudo tar -xz -C /usr/local/bin keyzulaAktualisieren:
brew update && brew upgrade keyzulaDie Archive und eine SHA256SUMS-Datei werden in den Releases von KeyZula/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 GitHubget 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.comKonten mit SSO- oder passwortloser Anmeldung (vertrauenswürdige Geräte) werden in der Kommandozeile noch nicht unterstützt.
SSH-Agent starten
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-addwird abgelehnt; verwalten Sie Schlüssel im Tresor.
ssh-Konfiguration
keyzula ssh add-config gibt den passenden Konfigurationsausschnitt für Ihr System aus. Um KeyZula-Schlüssel 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.comDer Socket wird mit Berechtigungen angelegt, die nur Ihnen Zugriff erlauben (0600). Ist XDG_CONFIG_HOME gesetzt, ändert sich der Pfad entsprechend; keyzula ssh add-config zeigt immer den richtigen.
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--daemonkombinieren; starten Sie den Agent im Vordergrund in einem eigenen Terminal-Tab.--lock-after: sperrt den Agent nach so viel Inaktivität (Standard12h;0= nie). Dauern schreiben Sie etwa als30moder2h.keyzula locklöscht die Schlüssel aus dem Speicher;keyzula unlockfragt nach Ihrem Master-Passwort und entsperrt den Agent wieder.
Git-Commits signieren
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 truessh-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,codeoder die Bezeichnung eines eigenen Felds. - Schreiben Sie ein
/in einem Namen als%2Fund setzen Sie Referenzen in der Shell immer in Anführungszeichen.
keyzula read "kz://Production/Postgres/password"
keyzula read -n "kz://~/GitHub/totp"keyzula 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.shkeyzula 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.ymlAlle Referenzen werden aufgelöst, bevor etwas startet; schlägt auch nur eine fehl, wird nichts gestartet oder geschrieben.
Dienstkonten: CI, Server und KI-Agenten
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.1.0/keyzula-1.1.0-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.ymlkeyzula 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.pySicherheitshinweise
- 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 nach
~/.config/keyzula. Außer der ausdrücklich angeforderteninject -o-Ausgabe wird kein Geheimnis auf die Festplatte geschrieben. - Abrufe mit
getund 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.