SKULLS & BONES

skulls-and-bones.org

ZURÜCK ZUR JOURNAL-ÜBERSICHT
Security & DevOps

Praxis-Leitfaden: Vollständige Migration von OpenSSH zu S&B NetGate (sb-ssh)

2026-09-07Skulls & Bones Lab

Schluss mit statischen authorized_keys: Der Umstieg auf S&B NetGate

Statische SSH-Schlüssel (id_ed25519 oder id_rsa) gehören seit Jahrzehnten zum Standardrepertoire der Systemadministration – und stellen gleichzeitig eine der größten Sicherheitslücken dar.

In typischen Entwicklungs- und Produktivumgebungen führt dies zu bekannten Problemen:

  • Key-Sprawl: Niemand weiß mehr genau, welcher Entwickler welche Schlüssel auf welchen Servern in ~/.ssh/authorized_keys hinterlegt hat.
  • Unmögliches Offboarding: Verlässt ein Mitarbeiter oder externer Dienstleister das Unternehmen, müssen Server manuell abgesucht und bereinigt werden.
  • Mangelnde Zurechenbarkeit: Logs auf Zielservern protokollieren meist nur "Accepted publickey for root", nicht aber, wer hinter dem Zugriff stand.
  • Verlorene Laptops: Ein unverschlüsselter oder schwach geschützter Privatschlüssel auf einem verlorenen Laptop kompromittiert sofort das gesamte Netzwerk.

Mit S&B NetGate (sb-ssh) stellen wir eine 100% freie, quelloffene und in Rust entwickelte Alternative bereit, die diesen Key-Sprawl durch kurzlebige OpenSSH User-Zertifikate (z. B. 8 Stunden Gültigkeit) und OAuth2/OIDC-Browser-Logins ablöst.

In diesem Praxis-Leitfaden zeigen wir, wie der Umstieg innerhalb von 5 Minuten und ohne Unterbrechung bestehender Dienste gelingt.

Die 5 Migrationsschritte im Detail

Schritt 1: Bestehende Hosts & Konfigurationen importieren

Sie müssen keine Hostnamen oder IP-Adressen manuell neu tippen. sb-ssh liest Ihre bestehende ~/.ssh/config automatisch beim Start ein und überführt alle Hosts nahtlos in seinen lokalen Tresor (~/.sb-ssh/servers.toml).

Installieren und direkt starten:

cargo install --git https://github.com/Skulls-and-Bones/sb-ssh.git
sb-ssh list

sb-ssh list zeigt Ihnen alle importierten Server — inklusive Hosts, Ports, Benutzer und ProxyJump-Kaskaden aus Ihrer ~/.ssh/config. Server, die Sie manuell hinzufügen möchten:

sb-ssh add prod-web-01 192.168.1.10 --user root --port 22 --tags "prod,web"

Keine Downtime: Ihre bestehenden Private Keys und Zertifikate funktionieren während der gesamten Umstellungsphase transparent weiter — sb-ssh fällt bei Bedarf automatisch auf ~/.ssh/identity_file zurück.

Schritt 2: Drop-in Ersatz für System-Tools aktivieren

sb-ssh versteht alle standardmäßigen OpenSSH-Flags (-p, -i, -o, -T, -v, -q, -D, -L) und leitet non-interactive Befehle automatisch als Raw-Stream weiter.

Sie können OpenSSH daher systemweit ersetzen, ohne dass Skripte oder Tools brechen:

# Windows (PowerShell als Benutzer):
Copy-Item "$env:USERPROFILE\.cargo\bin\sb-ssh.exe" "$env:USERPROFILE\.cargo\bin\ssh.exe" -Force

# Linux / macOS:
sudo ln -sf ~/.cargo/bin/sb-ssh /usr/local/bin/ssh

Git-Transfers nahtlos absichern

Setzen Sie einfach die Umgebungsvariable GIT_SSH_COMMAND:

$env:GIT_SSH_COMMAND = "sb-ssh"
git pull origin main

Ab diesem Moment laufen Git-Operationen, CI/CD-Pipelines und sogar VS Code Remote-SSH vollkommen transparent über die hochperformante Pure-Rust SSH2-Engine.

Schritt 3: Ziel-Server schlüsselfrei machen (Zero-Key Transition)

Anstatt für jeden Benutzer Schlüssel auf dem Server zu hinterlegen, hinterlegen Sie ein einziges Mal den öffentlichen Schlüssel der S&B Certificate Authority (CA). Der CA-Key wird beim ersten Start von sb-ssh automatisch lokal generiert und liegt in ~/.sb-ssh/ca_key.pub.

  1. Lokal ausführen — fertige Befehle werden generiert:
sb-ssh server-init

server-init liest Ihren persönlichen CA Public Key aus ~/.sb-ssh/ca_key.pub und gibt fertig kopierbare Shell-Befehle mit Ihrem echten Key aus, z. B.:

  # 1. S&B CA Public Key hinterlegen:
  sudo mkdir -p /etc/ssh
  echo 'ssh-ed25519 AAAAC3Nza...IHR_ECHTER_KEY S&B_NetGate_CA' | sudo tee /etc/ssh/sb_ca.pub

  # 2. In /etc/ssh/sshd_config eintragen:
  echo 'TrustedUserCAKeys /etc/ssh/sb_ca.pub' | sudo tee -a /etc/ssh/sshd_config
  sudo sshd -t && sudo systemctl reload ssh
  1. Diese Ausgabe auf dem Zielserver ausführen:

Kopieren Sie die von server-init generierte Ausgabe direkt in die SSH-Verbindung zu Ihrem Server. Die Befehle enthalten Ihren echten, individuellen CA-Key – Sie müssen nichts manuell eintragen.

Den aktuellen CA Public Key können Sie jederzeit auch direkt einsehen:

sb-ssh status

Was bedeutet das?
Der Server akzeptiert fortan jede Verbindung, deren Zertifikat von Ihrer CA signiert wurde. Sie müssen nie wieder einen Schlüssel in ~/.ssh/authorized_keys eintragen oder manuell löschen.

Schritt 4: OAuth2 / OIDC Login aktivieren

Option A: GitHub-Login (sofort, ohne Konfiguration)

Der Standardprovider ist GitHub. Ein Login-Klick genügt:

sb-ssh login
# oder explizit:
sb-ssh login --provider github
  • Der Standardbrowser öffnet sich mit dem GitHub OAuth-Dialog.
  • Nach erfolgreichem Login generiert die lokale CA ein Just-In-Time Ed25519-Zertifikat mit 8 Stunden Gültigkeit.
  • Jeder Entwickler authentifiziert sich über seinen eigenen GitHub-Account. Scheidet er aus, wird der GitHub-Account deaktiviert — der Zugriff auf alle Server erlischt automatisch.

Option B: Lokaler Entwicklermodus (ohne Browser / Offline)

Für CI/CD-Pipelines, Air-Gapped-Umgebungen oder lokale Tests ohne IdP:

sb-ssh login --dev <username>

Dies erzeugt direkt ein lokales Entwickler-Zertifikat ohne Browser-Redirect.

Option C: Eigener OIDC-Provider (Keycloak, Authentik, etc.)

sb-ssh login --provider oidc

Die OIDC-Konfiguration (Client-ID, Issuer-URL) wird in ~/.sb-ssh/config.toml hinterlegt.

Mit sb-ssh status lässt sich der Login-Status und die verbleibende Gültigkeit jederzeit prüfen:

sb-ssh status
# Ausgabe z.B.:
#   ✓ OAuth-Sitzung:   AKTIV
#   ► Identität:       alice (alice@example.com)
#   ► Gültig bis:      ... (6h 11m verbleibend)

Schritt 5: BSI-Audit & Asciinema Recording aktivieren

Für Compliance-Audits nach BSI IT-Grundschutz (OPS.1.1.4 und DER.1) erfassen Sie administrative Sitzungen revisionssicher. Das Recording-Flag ist -r (Kurzform) oder --record:

# Sitzung verbinden und PTY-Stream aufzeichnen:
sb-ssh connect srv-prod-01 -r
# oder:
sb-ssh connect srv-prod-01 --record

Die Aufzeichnung wird automatisch in ~/.sb-ssh/recordings/<session_id>.cast gespeichert.

# BSI Audit-Tabelle aller Sitzungen im Terminal anzeigen:
sb-ssh audit

# Nur die letzten 5 Einträge:
sb-ssh audit --limit 5

# Rohe JSONL-Ausgabe für SIEM-Integration (Splunk, Elastic, Graylog):
sb-ssh audit --json

Die Audit-Datei selbst liegt unter ~/.sb-ssh/audit/sessions.jsonl und kann direkt ausgewertet werden.

# Sitzung offline mit Original-Timing und PTY-Events abspielen:
sb-ssh replay sb-20260907-182353-04a1
# oder direkt per Dateipfad:
sb-ssh replay ~/.sb-ssh/recordings/sb-20260907-182353-04a1.cast

Feature-Gegenüberstellung

Eigenschaft Herkömmliches OpenSSH S&B NetGate (sb-ssh)
Authentifizierung Statische Keys in authorized_keys 100% Zero-Key (8h Ephemeral Ed25519-Certs)
Identitäts-Anbindung Keine native IdP-Unterstützung GitHub, OIDC (Keycloak, Authentik), --dev Modus
Mitarbeiter-Offboarding Mühsames manuelles Suchen & Löschen Sofortiger Entzug über zentralen IdP
Terminal Dashboard Reine zeilenbasierte CLI Minimalistische Ratatui TUI mit Live-Ping
Sitzungsaufzeichnung Externe Tools (script, ttyrec) Natives Asciinema v2 Recording (-r) & Replay
BSI-Compliance Mühsames Parsen von syslog/auth.log Strukturierte JSON-Lines (~/.sb-ssh/audit/sessions.jsonl)
Dynamischer Proxy Komplizierte Parameterketten 1-Klick SOCKS5 (sb-ssh proxy <srv>)
Dateitransfer Auf externe scp.exe angewiesen Nativer Pure-Rust SFTP-Client (push/pull)

Fazit & Download

S&B NetGate beweist, dass moderne Zero-Trust-Sicherheit nicht mit Einbußen im Entwickler-Komfort einhergehen muss. Das Tool ist vollständig kostenlos unter der MIT-Lizenz verfügbar und lässt sich mit einem einzigen Befehl installieren:

cargo install --git https://github.com/Skulls-and-Bones/sb-ssh.git