Open Source von OpenPubkey SSH (OPKSSH) veröffentlicht – ein mit SSH integriertes Single-Sign-On-System

• Cloudflare hat OPKSSH (OpenPubkey SSH) als Open Source veröffentlicht
• OPKSSH ermöglicht die automatische Erzeugung und Nutzung von SSH-Schlüsseln per SSO-Login auf Basis von OpenID Connect
• Nutzer müssen öffentliche/private SSH-Schlüssel nicht mehr selbst verwalten oder auf Server verteilen
• So lässt sich ein identitätsbasierter Ansatz für die SSH-Authentifizierung einführen, ohne das SSH-Protokoll zu ändern

Hintergrund zu SSO und OpenID Connect

• SSO (Single Sign-On) ist ein Authentifizierungsverfahren, bei dem sich Nutzer einmal anmelden und dann auf mehrere Systeme zugreifen können
• OpenID Connect ist ein Protokoll, das häufig für SSO verwendet wird und ID-Tokens mit Nutzerinformationen ausstellt
• ID-Tokens enthalten Informationen wie die E-Mail-Adresse des Nutzers, aber keinen öffentlichen Schlüssel → daher nicht direkt für Sicherheitsprotokolle wie SSH nutzbar

Einführung in OpenPubkey

• OpenPubkey fügt dem ID-Token den öffentlichen Schlüssel des Nutzers hinzu und macht daraus ein PK Token
• Dadurch kann etwa bestätigt werden: „Google authentifiziert, dass der Nutzer [e-mail] den öffentlichen Schlüssel 0x123 verwendet“
• Das lässt sich ohne Änderungen am bestehenden OpenID-Connect-Protokoll anwenden

Rolle und Vorteile von OPKSSH

• OPKSSH integriert OpenPubkey in SSH und erzeugt per SSO-Login einmalige SSH-Schlüssel
• Es funktioniert ohne Änderungen am bestehenden SSH-Protokoll und lässt sich durch das Hinzufügen von nur zwei Zeilen zur Konfigurationsdatei aktivieren

• Verbesserte Sicherheit

  • Statt langlebiger Schlüssel werden einmalige SSH-Schlüssel verwendet → das reduziert Schäden bei Schlüsselverlust und begrenzt die Lebensdauer der Schlüssel
  • Standardmäßig laufen sie nach 24 Stunden ab, dies ist per Konfiguration änderbar

• Mehr Benutzerfreundlichkeit

  • Bereits durch das Ausführen des Befehls opkssh login lassen sich SSH-Schlüssel erzeugen und die Anmeldung durchführen
  • Es ist nicht mehr nötig, private SSH-Schlüssel auf mehrere Computer zu kopieren

• Bessere Sichtbarkeit für Administratoren

  • Statt schlüsselbasiertem Zugriff erfolgt die Zuordnung über E-Mail-Adressen → dadurch ist klar nachvollziehbar, wer ein Nutzer ist
  • Wird eine E-Mail wie [e-mail] in die Datei mit erlaubten Zugriffen eingetragen, ist der Zugriff sofort möglich

So funktioniert OPKSSH

• Wenn der Nutzer opkssh login ausführt:
  • Es werden temporäre öffentliche/private SSH-Schlüssel erzeugt
  • Im Browser erfolgt die Anmeldung beim OpenID Provider (z. B. Google)
  • Bei Erfolg wird über das OpenPubkey-Protokoll ein PK Token erzeugt, das den öffentlichen Schlüssel und die Nutzeridentität enthält
  • Im Verzeichnis .ssh werden eine öffentliche Schlüsseldatei mit dem PK Token und eine private Schlüsseldatei gespeichert
• Beim SSH-Verbindungsaufbau:
  • Der SSH-Client sendet den öffentlichen Schlüssel mit dem enthaltenen PK Token an den SSH-Server
  • Der Server prüft die Gültigkeit des öffentlichen Schlüssels über den als AuthorizedKeysCommand konfigurierten OpenPubkey-Verifier
  • Ist das PK Token gültig und steht die E-Mail-Adresse auf der Zugriffsliste, wird die Verbindung erlaubt

Lösung technischer Probleme

• Übertragung des PK Token: Das PK Token wird über das Erweiterungsfeld eines SSH-Zertifikats in den öffentlichen SSH-Schlüssel eingebettet
• Validierung auf dem Server: Über AuthorizedKeysCommand wird die Gültigkeitsprüfung des öffentlichen Schlüssels an ein benutzerdefiniertes Programm (OpenPubkey-Verifier) delegiert
• Prüfung der Übereinstimmung des öffentlichen Schlüssels: Es wird bestätigt, dass der öffentliche Schlüssel, der die SSH-Sitzung schützt, mit dem Schlüssel im PK Token übereinstimmt

Open Source und seine Bedeutung

• OPKSSH wurde unter der Apache-2.0-Lizenz auf GitHub veröffentlicht
• Zuvor war es nur auf Prototyp-Niveau, jetzt gibt es aber einen stabilen Release mit vollständiger SSH-Funktionalität
• Cloudflare pflegt oder garantiert das Projekt nicht, hat den Code jedoch an die OpenPubkey-Community gespendet

Wichtige Verbesserungen

• Voll nutzbare SSH-Funktionalität hinzugefügt
• Automatisches Installationsskript bereitgestellt
• Verbesserte Konfigurationstools enthalten

[GN⁺]

Hacker-News-Kommentare

• SSH-Zertifikate gibt es schon seit langer Zeit, und man kann eine eigene SSH-CA einrichten, um kurzlebige Zertifikate ausstellen zu lassen
  • Es gibt verschiedene Optionen, um Zertifikate automatisch zu erhalten, darunter das Projekt step-ca
  • step-ca kann mit OAUTH/OIDC-Systemen und Cloud-Anbietern kommunizieren
  • Es gibt auch kommerzielle Lösungen
• Bevorzugt wird eine Methode mit SSH-CA und Hardware
  • Dadurch muss SSHD keinen Code von Drittanbietern aufrufen, was die Angriffsfläche und Angriffsvektoren minimieren kann
  • Schlüsselabfluss oder Wiederverwendungsangriffe können vollständig verhindert werden
  • Aus Administratorsicht ist es vorteilhaft, dass sich alles mit dem Standardbefehl ssh-keygen erledigen lässt
• Es wird bezweifelt, dass ID-Tokens das SSH-Protokoll nicht direkt absichern können, weil sie keine öffentlichen Benutzerschlüssel enthalten
  • SSH-Authentifizierung muss nicht zwingend schlüsselbasiert sein
  • Es wird gefragt, ob sich das über GSSAPI hätte umsetzen lassen
• Mit Teleport wird zertifikatsbasierte SSH-Authentifizierung durchgeführt, wobei per SSO-Authentifizierung kurzlebige Zertifikate ausgestellt werden
  • Das bietet Vorteile bei Zugriffskontrolle und Audit-Logs
• Es wird an einer SSH-Alternative namens Terminalwire gearbeitet
  • Sie eignet sich für die einmalige Ausführung von Befehlen gegen SaaS von Entwickler-Workstations aus
  • Ähnlich wie bei SSH wird stdio vom Server zum Client gestreamt, bietet aber zusätzliche Befehle
• Ein Vergleich mit der SSH-Schlüsseltechnologie von Userify
  • Userify verwendet verteilte gewöhnliche Schlüssel und zentralisiert nur die zentrale Control Plane
  • Auch wenn der Authentifizierungsserver offline ist, kann man sich weiterhin auf Servern anmelden
  • Es gibt Funktionen zum Beenden von Benutzersitzungen und zum Löschen von Konten
• Als Autor des Blogbeitrags und Hauptmitwirkender an opkssh ist man bereit, Fragen zu beantworten
• Es ist schwer zu erkennen, worin der Unterschied zum Betrieb einer SSH-CA mit OIDC-Unterstützung besteht
  • Server müssen lediglich dem Schlüssel der CA vertrauen
• Es gibt einen OpenSSH-Fork, der X.509-Zertifikat-CAs unterstützt
  • Es wird als interessant empfunden, dass ein Standard, der öffentliche Schlüssel als Token zurückgibt, und ein serverseitiges Authentifizierungs-Binary, das damit SSH-Logins ermöglicht, als innovativ dargestellt werden