SSH-Zertifikate: die bessere SSH-Erfahrung

 (jpmens.net)
6 Punkte von GN⁺ 25 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • SSH-Zertifikate lösen den umständlichen Charakter der herkömmlichen SSH-Authentifizierung auf Basis öffentlicher Schlüssel und bieten automatisches Vertrauen zwischen Client und Server
  • Unterstützt seit OpenSSH 5.4; eine CA (Zertifizierungsstelle) signiert Benutzer- und Host-Schlüssel, sodass Authentifizierung ohne Änderungen an authorized_keys möglich ist
  • Zertifikate können Gültigkeitsdauer, erlaubte Benutzer (Principals), Zugriffs-IP-Adressen, erzwungene Befehle (force-command) usw. enthalten und unterstützen so eine feingranulare Zugriffskontrolle
  • Das TOFU(Trust on First Use)-Verfahren entfällt, und bei Änderungen des Host-Schlüssels ist eine sichere Verbindung ohne Warnung möglich
  • Mit automatischen Signaturservern oder Tools lassen sich SSH-Verwaltung in großen Serverumgebungen automatisieren und die Sicherheit verbessern

Überblick über SSH-Zertifikate und Grenzen der bisherigen SSH-Schlüssel-basierten Authentifizierung

  • Beim Aufbau einer SSH-Verbindung muss der Host-Key-Fingerprint eines Servers, zu dem man sich erstmals verbindet, geprüft werden; die meisten Nutzer verifizieren ihn jedoch nicht und geben einfach „yes“ ein – ein TOFU(Trust on First Use)-Verfahren
    • Administratoren können den Fingerprint direkt auf dem Server prüfen oder mit dem Befehl ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key verifizieren
  • Eine Authentifizierung auf Basis öffentlicher Schlüssel ermöglicht die Anmeldung ohne Passwort, erfordert jedoch die Verteilung des öffentlichen Schlüssels in die Datei authorized_keys auf jedem Server
  • Mit dem SSH-Agenten (ssh-agent) kann der private Schlüssel im Speicher gehalten werden, sodass wiederholte Eingaben entfallen
  • Grenzen des bisherigen Verfahrens
    • Der öffentliche Schlüssel muss für jeden Benutzer auf die Server kopiert werden
    • Bei Änderungen des Host-Schlüssels erscheint auf dem Client eine Warnmeldung
    • TOFU macht die Vertrauensverwaltung umständlich

SSH-Zertifikate und Zertifizierungsstellen (CA)

  • SSH-Zertifikate (Certificate) werden seit OpenSSH 5.4 (März 2010) unterstützt und erweitern das bestehende SSH-Schlüsselformat
  • Eine SSH-CA besteht aus einem SSH-Schlüsselpaar, wobei der öffentliche Schlüssel als Vertrauensanker dient
  • Wichtige Vorteile
    • Keine Änderungen an der Datei authorized_keys auf dem Server erforderlich
    • Keine Warnungen beim Austausch des Host-Schlüssels
    • Automatisches Vertrauen durch Wegfall des TOFU-Verfahrens
    • Zertifikate können erlaubte Benutzer (Principals), erlaubte IPs, Gültigkeitsdauer, erzwungene Befehle (force-command) usw. enthalten
    • Nach Ablauf des Zertifikats wird der Zugriff automatisch gesperrt

Aufbau einer SSH-CA und Signaturprozess

  • Auf dem CA-System wird mit dem ECDSA-Algorithmus ein CA-Schlüsselpaar erzeugt
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • Der Benutzer übermittelt seinen öffentlichen Schlüssel (*.pub) an die CA, und die CA signiert ihn und stellt ein Zertifikat (*-cert.pub) aus
    • Beispiel: ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • Server-Konfiguration
    • Den öffentlichen CA-Schlüssel unter /etc/ssh/ssh-ca.pub speichern und die Einstellung TrustedUserCAKeys hinzufügen
    • Den Host-Schlüssel des Servers mit der CA signieren (ssh-keygen -h -s CA/ssh-ca ...) und unter HostCertificate eintragen
  • Client-Konfiguration
    • In der Datei known_hosts eine Zeile mit @cert-authority hinzufügen
    • Beispiel: @cert-authority *.example.com $(cat CA/ssh-ca.pub)

Verbindung und Verifikation auf Basis von SSH-Zertifikaten

  • Benutzer verbinden sich mit dem signierten Zertifikat zusammen mit dem privaten Schlüssel (ssh -i jane -l jane alice.example.com)
  • Im Server-Log werden ID, Seriennummer (serial) und CA-Fingerprint des Zertifikats protokolliert
  • Mehrere Hostnamen oder IP-Adressen können als Principal in das Zertifikat aufgenommen werden
  • Bei einem Anmeldeversuch mit einem Benutzer, der nicht als Principal im Zertifikat eingetragen ist, erscheint der Fehler „Certificate invalid: name is not a listed principal“
  • Mit erzwungenen Befehlen (force-command) oder erlaubten IPs (source-address) im Zertifikat ist eine feingranulare Zugriffskontrolle möglich

Checkliste für Prüfung und Fehlerbehebung

  • Zu prüfende Punkte auf der Serverseite

    • Einstellung TrustedUserCAKeys und Vorhandensein des öffentlichen CA-Schlüssels
    • Signatur des Host-Schlüssels und Angabe von HostCertificate
    • Ein Neustart von sshd ist erforderlich

  • Zu prüfende Punkte auf der Clientseite

    • Der Benutzerschlüssel muss von der CA signiert sein
    • Der @cert-authority-Eintrag in known_hosts und der Principal müssen übereinstimmen
    • Bei Ablauf des Zertifikats erscheint die Meldung „Certificate invalid: expired“
    • Bei nicht passenden Zertifikatsbeschränkungen wird zur Passworteingabe aufgefordert
    • Wird ein Zertifikat zum SSH-Agenten hinzugefügt, werden Schlüssel und Zertifikat beide registriert (ssh-add jane)
    • Funktionen lassen sich beim Signieren über Optionen (-O) steuern
    • Beispiel: Mit -O clear werden alle Berechtigungen entfernt und nur permit-agent-forwarding, permit-port-forwarding erlaubt

Automatisierung von Host-Key-Zertifikaten

  • Mit dem Python-Modul sshkey-tools und BottlePy lässt sich ein automatischer Signaturserver (hkbot) implementieren
    • Auf dem CA-Server hkbot.py ausführen; beim Hochladen eines öffentlichen Host-Schlüssels per HTTP-Anfrage wird dieser automatisch signiert
    • Auf dem Client automatische Installation mit dem Befehl curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh
    • Nach Änderung von /etc/ssh/sshd_config und Prüfung wird die Konfiguration mit systemctl restart sshd angewendet
  • Danach sind bei SSH-Verbindungen automatisches Vertrauen und Login auf Basis von Zertifikaten möglich

Zusammenfassung der Vorteile von SSH-Zertifikaten

  • Kein TOFU erforderlich, automatisches Vertrauen zwischen Client und Server
  • Durch kurzlebige Zertifikate ist temporäre Zugriffskontrolle möglich
  • Nach Ablauf des Zertifikats wird der Zugriff automatisch gesperrt; ein Aufräumen von authorized_keys ist nicht nötig
  • Erzwungene Befehle, PTY-Beschränkungen, Kontrolle von Zugriffs-IPs und andere feingranulare Richtlinien sind möglich
  • Mit Automatisierungstools lässt sich die Verwaltung großer Serverumgebungen vereinfachen
  • Als verwandtes Projekt wird Smallstep SSH vorgestellt

Weiterführende Materialien

Update

  • Eine SSH-CA ist besonders nützlich in Umgebungen mit eigenen Servern und Root-Rechten
  • In Mehrbenutzersystemen werden die bisherigen Verfahren mit known_hosts und authorized_keys weiterhin benötigt
  • Entwurf zur Standardisierung des SSH-Zertifikatsformats: draft-miller-ssh-cert-06

Verwandte Beiträge

1 Kommentare

 
GN⁺ 25 일 전
Hacker-News-Kommentare

  • Es überrascht mich, dass Leute immer noch SSH-Passwörter verwenden
    Vor allem in großen Unternehmensumgebungen greifen oft mehrere Passwort-Richtlinien ineinander, sodass schon das bloße Einloggen auf einen Server viel Zeit kostet
    Selbst wenn man ihnen sagt, sie sollen mit ssh-keygen Schlüssel verwenden, denken die meisten nur: „Muss ich irgendwann mal ausprobieren“ – und tun es am Ende doch nicht

    • Schlüssel sind nützlich, wenn es für Einzelpersonen oder im Unternehmen ein zentralisiertes Verwaltungssystem gibt
      In der Praxis wird aber leicht alles chaotisch, etwa wenn derselbe öffentliche Schlüssel auf mehreren Servern genutzt oder Schlüssel geteilt werden
      Passwörter haben zumindest den Vorteil, einfach zu sein
    • Ich verwalte meine SSH-Schlüssel seit Jahren mit einem Yubikey-basierten HSM
      Es gibt kein Passwort, aber beim Login muss ich den Yubikey physisch berühren
    • Die Nutzung verteilter Schlüssel wie ssh-copy-id erleichtert es Angreifern, sich innerhalb eines Netzwerks lateral zu bewegen, deshalb blockieren viele Organisationen das

  • Alle paar Monate entdeckt wieder jemand SSH-Zertifikate neu und schreibt einen Blogpost darüber
    Ich habe selbst vor 15 Jahren einen Beitrag dazu geschrieben, und aus heutiger Sicht war der unzureichend

    • Viele verwechseln Schlüssel und Zertifikate
      Sogar Security Engineers vergessen manchmal, dass sie Schlüsselauthentifizierung und nicht SSH-Zertifikate verwenden
    • SSH-Zertifikate sind nützlich, weil sie einem bestimmten Benutzer Zugriff mit begrenzter Laufzeit und eingeschränkten Rechten geben können
    • Ich kannte SSH-Zertifikate zwar auch, bin aber nie vom schlüsselbasierten Ansatz weggekommen
      Die Schlüssel auf vielen Servern manuell zu verwalten, ist einfach zu mühsam
      Ich überlege gerade, ob sich der Umstieg jetzt doch noch lohnt
    • Als wir vor 10 Jahren in meiner Firma eine SSH-CA aufgebaut haben, haben wir uns an dem obigen Blogpost orientiert

  • Der TOFU(Trust On First Use)-Ansatz ist simpel, trägt aber ziemlich weit
    Auf meinen Servern reicht es mir, den Host-Schlüssel einmal direkt zu prüfen
    In großen Unternehmen könnte man die Liste interner öffentlicher Schlüssel auf einer intern per SSL signierten Website veröffentlichen
    Aber in Umgebungen mit vielen oder häufig wechselnden Servern sind Zertifikate deutlich besser, und TOFU stößt in vielerlei Hinsicht an Grenzen
    Ich wünschte, Browser hätten auch eine Funktion, die meldet, wenn sich der TLS-Schlüssel eines Servers ändert

    • Ich nutze SSH seit 1996, aber ich habe noch nie jemanden erlebt, der öffentliche Schlüssel manuell überprüft
      Die meisten tippen einfach „yes“ und machen weiter

  • In der Firma verschwenden wir wegen der SSL-Inspektion von Zscaler massiv Zeit und Geld
    Wenn der Fehler „self-signed certificate in certificate chain“ auftaucht, ist das jedes Mal ein Ärgernis

    • Ich habe Zscaler auf dem Windows 11 eines Freundes analysiert, und das war fast auf Malware-Niveau
      Es installiert ein eigenes Root-Zertifikat und sperrt die Browser-Einstellungen, damit man keinen Proxy verwenden kann
      Selbst wenn man Konfigurationsdateien von Firefox oder Chrome ändert, wird das sofort wieder überschrieben
      Sogar zum Deaktivieren über die GUI braucht man ein IT-Passwort
      Nur geringfügig besser als Cybereason-Antivirus
    • Unser Cisco Umbrella ist genauso
      Es zerstört praktisch alle HTTP-basierten Protokolle
      Git, RubyGems, go mod, Nix und unzählige andere Tools gehen kaputt
      Der Anbieter behauptet, es sei „transparent“, aber in Wirklichkeit ist es das überhaupt nicht
      Die Fehlersuche dauert Stunden, und die meisten Administratoren ahnen nicht, wie zerstörerisch das ist
    • Zur Klarstellung: SSH-Zertifikate sind nicht dasselbe wie X.509-Zertifikate

  • Im Artikel wurden nur die Vorteile von CA-Zertifikaten erwähnt, aber die Nachteile gibt es natürlich ebenfalls
    Ich habe noch nie ein Sicherheitsproblem durch TOFU erlebt

    • „Es gab keinen Vorfall, also ist es sicher“ ist dieselbe Logik wie keinen Sicherheitsgurt tragen zu müssen
      Falls SSH-Zertifikate Nachteile haben, würde mich interessieren, welche das konkret sind
    • TOFU ist bequem, aber nicht zwingend notwendig
      Wenn man die Sicherheit erhöhen will, kann man öffentliche Schlüssel über einen sicheren Kanal wie USB austauschen
      Auch mit Zertifikaten muss man letztlich denselben Schritt gehen; nur die Verantwortung verschiebt sich vom Benutzer zum Administrator
      In großen Organisationen können Zertifikate nützlich sein, aber die grundsätzliche Sicherheit ist gleich
    • Wenn sich die CA-Konfiguration vorab einrichten lässt, kann man TOFU vermeiden
      Man kann sie in Installationsskripte oder Deployment-Images aufnehmen
      TOFU ist nur relevant, wenn man auf bereits eingerichtete Systeme zugreift
    • „Es gab bisher noch keinen Sicherheitsvorfall durch TOFU“ heißt nur, dass es bisher noch keinen gab

  • In unserer dev/stg-Umgebung wird jeden Tag die Hälfte der Maschinen neu installiert
    Dank SSH-Host-Zertifikaten müssen wir weder known_hosts löschen noch Schlüssel beibehalten, was viel bequemer ist

  • Ich entwickle als Nebenprojekt ein Tool namens Sshifu
    Es erleichtert Login auf Basis von SSH-Zertifikaten und SSO
    Man installiert sshifu-server auf dem Server und nutzt ihn als CA, und jeder SSH-Server wird so konfiguriert, dass er dieser CA vertraut
    Für den Benutzer reicht dann der Befehl npx sshifu zum Einloggen
    Siehe das GitHub-Repository

  • In echten Produktionsumgebungen führt zertifikatsbasierter Zugriff zu komplexen Verwaltungsproblemen
    Zertifikatsablauf, Entfernen von Benutzern, Login bei Serverausfällen und viele andere Themen treten auf
    Bei Userify beschäftigen wir uns seit 15 Jahren mit solchen Problemen, und eine stabile SSH-Authentifizierungsinfrastruktur aufzubauen ist alles andere als einfach

    • Trotzdem halte ich ein SaaS-Modell für die schlechteste Wahl

  • Ich habe pico.sh um Unterstützung für SSH-Zertifikate erweitert, und das war sehr nützlich, weil sich damit RBAC-artige Zugriffskontrolle umsetzen ließ
    Siehe die Dokumentation

  • In Produktion zentralisieren SSH-Zertifikate die Komplexität eher noch und verschärfen dadurch Probleme
    Eine einzelne CA muss ständig verfügbar sein, und bei einem Ausfall ist der gesamte Zugriff blockiert
    Dazu kommen praktische Probleme wie TTL-Abstimmung, Verwaltung der Vertrauenswurzel und schwieriges Debugging
    Am Ende führen die Leute doch wieder Caches oder Agenten ein
    Wir gehen den umgekehrten Weg und lassen jeden Knoten Benutzerinformationen per HTTPS in die lokale authorized_keys synchronisieren
    So bleibt die zentrale Kontrolle erhalten, während Ausfälle lokal begrenzt bleiben
    Bei Userify nutzen wir diesen Ansatz; er deckt nicht nur Authentifizierung, sondern auch Berechtigungsverwaltung ab
    Zertifikate allein lösen keine Probleme wie Benutzeranlage, sudo-Rollen oder das Aufräumen von Home-Verzeichnissen

    • Es kam die Frage auf, wie dabei TOFU gelöst wird