
In diesem Beitrag entwickeln wir ein Verfahren für den Notfallzugang zu SSH-Hosts unter Verwendung von Sicherheits-Hardware-Token im Offline-Modus. Dies ist nur einer der Ansätze, den Sie an Ihre Bedürfnisse anpassen können. Wir werden die SSH-Zertifizierungsstelle für unsere Hosts auf dem Sicherheits-Hardware-Token speichern.Dieses Schema funktioniert auf nahezu jedem OpenSSH, einschließlich SSH mit Single Sign-On.
Warum das Ganze? Nun, das ist eine Notfalloption. Es ist eine Backdoor, die Ihnen Zugang zu Ihrem Server ermöglicht, falls aus irgendeinem Grund nichts anderes funktioniert.
Warum Zertifikate anstelle von öffentlichen/privaten Schlüsseln für den Notfallzugang verwenden?
- Im Gegensatz zu öffentlichen Schlüsseln kann die Gültigkeitsdauer von Zertifikaten sehr kurz sein. Sie können ein Zertifikat generieren, das nur 1 Minute oder sogar 5 Sekunden gültig ist. Nach Ablauf dieser Zeit ist das Zertifikat für neue Verbindungen unbrauchbar. Dies eignet sich perfekt für den Notfallzugang.
- Sie können ein Zertifikat für jedes Konto auf Ihren Hosts erstellen und solche 'einmaligen' Zertifikate bei Bedarf an Kollegen senden.
Was Sie benötigen
- Sicherheitshardware-Token, die residenten Schlüssel unterstützen.
Residenten Schlüssel sind kryptografische Schlüssel, die vollständig im Sicherheits-Token gespeichert sind. Manchmal sind sie durch eine alphanumerische PIN geschützt. Der öffentliche Teil des residenten Schlüssels kann bei Bedarf zusammen mit dem Descriptor des privaten Schlüssels aus dem Sicherheits-Token exportiert werden. USB-Token der Serie Yubikey 5 unterstützen residenten Schlüssel. Es wird empfohlen, dass sie ausschließlich für den Notzugriff auf den Host verwendet werden. Für diesen Beitrag werde ich nur einen Schlüssel verwenden, aber Sie sollten einen zusätzlichen zur Sicherung haben. - Ein sicherer Ort zur Aufbewahrung dieser Schlüssel.
- OpenSSH Version 8.2 oder höher auf Ihrem lokalen Computer und auf den Servern, auf die Sie im Notfall zugreifen möchten. Ubuntu 20.04 wird mit OpenSSH 8.2 ausgeliefert.
- (optional, aber empfehlenswert) Ein CLI-Tool zur Überprüfung von Zertifikaten.
Vorbereitung
Zuerst müssen Sie eine Zertifizierungsstelle erstellen, die sich auf dem Sicherheitsschlüssel befindet. Stecken Sie den Schlüssel ein und starten Sie:
$ ssh-keygen -t ecdsa-sk -f sk-user-ca -O resident -C [security key ID]Als Kommentar (-C) habe ich yubikey-9-512-742@smallstep.com angegeben, um mir zu merken, zu welchem Sicherheitsschlüssel diese Zertifizierungsstelle gehört.
Neben dem Hinzufügen des Schlüssels zu Yubikey werden lokal zwei Dateien generiert:
- sk-user-ca, ein Schlüsseldescriptor, der auf den privaten Schlüssel verweist, der im Sicherheitsschlüssel gespeichert ist,
- sk-user-ca.pub, welcher der öffentliche Schlüssel für Ihre Zertifizierungsstelle sein wird.
Aber keine Sorge, im Yubikey befindet sich noch ein privater Schlüssel, der nicht extrahiert werden kann. Daher ist alles sicher.
Fügen Sie auf den Hosts im Benutzerkontext root (falls noch nicht geschehen) in die Konfiguration Ihres SSHD (/etc/ssh/sshd_config) Folgendes ein:
TrustedUserCAKeys /etc/ssh/ca.pubFügen Sie dann den öffentlichen Schlüssel (sk-user-ca.pub) in /etc/ssh/ca.pub ein.
Starten Sie den Daemon neu:
# /etc/init.d/ssh restartJetzt können wir versuchen, auf den Host zuzugreifen. Aber zuerst benötigen wir ein Zertifikat. Erstellen Sie ein Schlüsselpaar, das mit dem Zertifikat verknüpft ist:
$ ssh-keygen -t ecdsa -f emergencyZertifikate und SSH-Paare
Manchmal hat man den Drang, ein Zertifikat als Ersatz für ein Schlüsselpaar zu verwenden. Doch zur Authentifizierung eines Nutzers reicht ein Zertifikat nicht aus. Jedes Zertifikat hat auch einen privaten Schlüssel, der mit ihm verbunden ist. Deshalb müssen wir dieses Paar "Notfall"-Schlüssel generieren, bevor wir uns selbst ein Zertifikat ausstellen. Wichtig ist, dass wir das signierte Zertifikat dem Server vorlegen, zusammen mit dem Schlüsselpaar, für das wir den privaten Schlüssel besitzen.So bleibt der Austausch von öffentlichen Schlüsseln nach wie vor wichtig. Das funktioniert sogar mit Zertifikaten. Zertifikate befreien den Server einfach von der Notwendigkeit, öffentliche Schlüssel zu speichern.
Erstellen Sie nun das Zertifikat selbst. Ich benötige die Authentifizierung des Benutzers ubuntu im Zeitrahmen von 10 Minuten. Sie können es nach Ihrem eigenen Ermessen tun.
$ ssh-keygen -s sk-user-ca -I test-key -n ubuntu -V -5m:+5m emergencySie werden aufgefordert, das Zertifikat mit einem Fingerabdruck zu signieren. Sie können zusätzliche Benutzernamen hinzufügen, die durch Kommas getrennt sind, z.B. -n ubuntu,carl,ec2-user.
Das ist es, jetzt haben Sie ein Zertifikat! Jetzt müssen die richtigen Berechtigungen festgelegt werden:
$ chmod 600 emergency-cert.pubNach dieser Schritt können Sie den Inhalt Ihres Zertifikats einsehen:
$ step ssh inspect emergency-cert.pubSo sieht meines aus:
emergency-cert.pub
Typ: ecdsa-sha2-nistp256-cert-v01@openssh.com Benutzerzertifikat
Öffentlicher Schlüssel: ECDSA-CERT SHA256:EJSfzfQv1UK44/LOKhBbuh5oRMqxXGBSr+UAzA7cork
Signierende CA: SK-ECDSA SHA256:kLJ7xfTTPQN0G/IF2cq5TB3EitaV4k3XczcBZcLPQ0E
Schlüssel-ID: "test-key"
Seriennummer: 0
Gültig: von 2020-06-24T16:53:03 bis 2020-06-24T17:03:03
Berechtigte:
ubuntu
Kritische Optionen: (keine)
Erweiterungen:
permit-X11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rcHier ist der öffentliche Schlüssel – das ist der von uns erstellte Notfall-Schlüssel, und er ist mit der Zertifizierungsstelle sk-user-ca verbunden.
Endlich sind wir bereit, den SSH-Befehl auszuführen:
$ ssh -i emergency ubuntu@my-hostname
ubuntu@my-hostname:~$- Jetzt können Sie Zertifikate für jeden Benutzer auf dem Host erstellen, der Ihrer Zertifizierungsstelle vertraut.
- Sie können emergency löschen. Sie können sk-user-ca behalten, aber es ist nicht nötig, da er auch auf dem Sicherheitsschlüssel vorhanden ist. Vielleicht möchten Sie auch den ursprünglichen PEM-Öffentlichen Schlüssel von Ihren Hosts entfernen (z. B. in ~/.ssh/authorized_keys für den Benutzer ubuntu), wenn Sie ihn für den Notzugang verwendet haben.
Notfallzugang: Aktionsplan
Fügen Sie den Sicherheitsschlüssel ein und führen Sie den Befehl aus:
$ ssh-add -KDamit fügen Sie den öffentlichen Schlüssel der Zertifizierungsstelle und den Schlüsseldescriptor zum SSH-Agenten hinzu.
Exportieren Sie nun den öffentlichen Schlüssel, um ein Zertifikat zu erstellen:
$ ssh-add -L | tail -1 > sk-user-ca.pubErstellen Sie ein Zertifikat mit einer Gültigkeitsdauer von beispielsweise nicht mehr als einer Stunde:
$ ssh-keygen -t ecdsa -f emergency
$ ssh-keygen -Us sk-user-ca.pub -I test-key -n [username] -V -5m:+60m emergency
$ chmod 600 emergency-cert.pubUnd jetzt erneut SSH:
$ ssh -i emergency username@hostWenn Ihre Datei .ssh/config Probleme bei der Verbindung verursacht, können Sie ssh mit dem Parameter -F none starten, um ohne diese auszukommen. Wenn Sie das Zertifikat einem Kollegen senden müssen, ist die einfachste und sicherste Option . Dafür benötigen Sie nur zwei Dateien – in unserem Fall sind das emergency und emergency-cert.pub.
Was mir an diesem Ansatz gefällt, ist die Hardwareunterstützung. Sie können die Sicherheitsschlüssel in einem Safe aufbewahren, und sie gehen nirgendwohin.
Im Auftrag der Werbung
Epische Server — ist mit leistungsstarken AMD-Prozessoren, einer CPU-Kernfrequenz von bis zu 3,4 GHz. Die maximale Konfiguration löst praktisch jede Aufgabenstellung – 128 CPU-Kerne, 512 GB RAM, 4000 GB NVMe. Machen Sie mit!
Quelle: habr.com
