Die übliche Art, sich an einer Linux-Maschine in der Cloud anzumelden, ist ein SSH-Schlüssel: eine Datei auf Ihrem Rechner und ihr öffentliches Gegenstück, kopiert auf die Maschine. Das funktioniert, aber sehen Sie sich an, was es bedeutet, sobald es mehr als eine Person und mehr als eine Maschine gibt: Jeder Schlüssel muss auf jede Maschine kopiert werden, jede Person, die geht, lässt ihren Schlüssel auf allen zurück, bis jemand daran denkt, ihn zu löschen, und ein verlorener Schlüssel gilt für immer. Wissen Sie heute mit Sicherheit, wie viele Schlüssel sich an Ihrem Produktionsserver anmelden können und wem sie gehören?
SSH-Zertifikate lösen genau das. Es ist dieselbe Technik, die Simplio für seinen Ersatzschlüssel nutzt und dieselbe, die Lightsail für seine Webkonsole nutzt, und man muss kein Experte sein, um sie zu verstehen.
Bevor Sie anfangen: was die Begriffe bedeuten
- SSH-Schlüssel
- Ein Dateienpaar: der private (bleibt auf Ihrem Rechner, wird nie geteilt) und der öffentliche (wird auf die Maschine kopiert, in die Datei authorized_keys des Benutzers). Die Maschine lässt herein, wer beweist, den privaten zu besitzen.
- SSH-Zertifikat
- Ihr öffentlicher Schlüssel, signiert von einer Zertifizierungsstelle, mit einem Namen, einem Ablaufdatum und einer Liste von Benutzern, für die er gilt. Die Maschine muss Ihren Schlüssel nicht kennen: Es reicht, dass sie dem vertraut, der ihn signiert hat.
- Zertifizierungsstelle (CA)
- Ein weiterer SSH-Schlüssel, der aber nur zum Signieren dient. Sein öffentlicher Teil wird einmal auf die Maschinen kopiert; sein privater wird sehr gut verwahrt, denn wer ihn hat, kann Zertifikate signieren.
- Principal
- Der Benutzername, für den das Zertifikat gilt. Ein Zertifikat für "ubuntu" taugt nicht, um sich als "root" anzumelden.
- Gültigkeit
- Ab wann und bis wann das Zertifikat gilt. Das kann ein Jahr sein oder fünf Minuten.
- authorized_keys
- Die Datei im Ordner .ssh jedes Benutzers der Maschine mit den öffentlichen Schlüsseln, die sich als er anmelden dürfen. Sie akzeptiert auch eine besondere Zeile, die sagt: "Akzeptiere Zertifikate, die von dieser Zertifizierungsstelle signiert sind".
Schritt für Schritt
Verstehen Sie den Unterschied an einem Beispiel
Mit Schlüsseln: Damit Ana sich an zehn Maschinen anmelden kann, wird ihr öffentlicher Schlüssel in zehn Dateien kopiert. Wenn Ana geht, muss er an zehn Stellen gelöscht werden, und wird eine vergessen, kommt Ana (oder wer ihren Laptop hat) weiter hinein. Mit Zertifikaten: Die zehn Maschinen vertrauen einer Zertifizierungsstelle. Ana bekommt ein Zertifikat signiert, das bis Freitag gilt. Am Samstag kommt Ana in keine mehr hinein, ohne dass eine einzige Maschine angefasst wurde. Und wird ihr jeden Morgen ein neues signiert, gibt es nie etwas zu widerrufen.
Erstellen Sie eine Zertifizierungsstelle (einmal, auf Ihrem Rechner)
ssh-keygen -t ed25519 -f mi_ca -C "CA de mi empresa"Es entstehen zwei Dateien.
mi_caist der private Schlüssel: Bewahren Sie ihn in einem Passwortmanager oder auf einer verschlüsselten Festplatte auf und kopieren Sie ihn nie auf eine Maschine.mi_ca.pubist der, der auf die Maschinen kommt.Sagen Sie der Maschine, dass sie Ihrer Zertifizierungsstelle vertrauen soll
Es gibt zwei Wege. Der globale, in
/etc/ssh/sshd_config, gilt für alle Benutzer:TrustedUserCAKeys /etc/ssh/mi_ca.pubUnd der lokale, ohne die SSH-Konfiguration anzufassen: eine Zeile in der
authorized_keysdes Benutzers, die nur für ihn gilt:cert-authority,principals="ubuntu" ssh-ed25519 AAAA... CA de mi empresaDer zweite ist der richtige in Lightsail, denn Lightsail nutzt
TrustedUserCAKeysbereits für seine eigene Webkonsole, und es kann nur einen geben. Laden Sie SSH neu (sudo systemctl reload ssh), und die Maschine akzeptiert Ihre Zertifikate.Signieren Sie ein Zertifikat für eine Person
Die Person schickt Ihnen ihren öffentlichen Schlüssel (
id_ed25519.pub). Sie signieren ihn und geben dabei an, für welchen Benutzer er gilt und wie lange:ssh-keygen -s mi_ca -I "ana-portatil" -n ubuntu -V +1w id_ed25519.pubHeraus kommt
id_ed25519-cert.pub: Sie geben es ihr zurück, und sie legt es neben ihren Schlüssel.-Iist ein Name für das Protokoll der Maschine (so wissen Sie, wer sich angemeldet hat),-nder erlaubte Benutzer und-V +1weine Woche Gültigkeit. Sie können+5mangeben und haben ein Zertifikat für fünf Minuten.Melden Sie sich an und prüfen Sie
ssh -i id_ed25519 ubuntu@IP.DE.LA.MAQUINASSH nutzt das Zertifikat von selbst. Auf der Maschine zeigt Ihnen
sudo journalctl -u ssh | grep ana-portatildie Anmeldung mit dem Namen, den Sie beim Signieren vergeben haben. Nach Ablauf der Gültigkeit antwortet derselbe Befehl mit "Permission denied", ohne dass jemand etwas angefasst hat.Fügen Sie Bedingungen hinzu: nur von einer IP
Beim Signieren können Sie Einschränkungen hinzufügen. Die nützlichste: dass das Zertifikat nur von einer bestimmten Adresse aus gilt.
ssh-keygen -s mi_ca -I "copias-nocturnas" -n backup -V +1d -O source-address=203.0.113.10 id_backup.pubGelangt dieses Zertifikat nach außen, ist es von jeder anderen IP aus nutzlos. Genau das macht der Ersatzschlüssel von Simplio: Zertifikate für fünf Minuten, für einen einzigen Benutzer, gültig nur von der IP des Simplio-Servers aus.
Was schiefgehen kann
"Permission denied", obwohl das Zertifikat korrekt ist
Am häufigsten: Der Principal stimmt nicht überein (Sie haben für "ubuntu" signiert und melden sich als "admin" an), die Gültigkeit ist abgelaufen, oder die Uhrzeit der Maschine ist falsch (Zertifikate hängen von der Uhr ab; prüfen Sie mit date und aktivieren Sie die Zeitsynchronisierung).
Die Maschine hatte bereits TrustedUserCAKeys
Das ist bei Lightsail und einigen Images der Fall. Ändern Sie es nicht: Sie würden die Webkonsole verlieren. Nutzen Sie die Zeile cert-authority in der authorized_keys des Benutzers, die problemlos daneben bestehen kann.
Ich habe den privaten Schlüssel der CA verloren
Sie können keine weiteren Zertifikate signieren, aber die bereits signierten gelten bis zu ihrem Ablauf. Erstellen Sie eine neue CA und ersetzen Sie den öffentlichen Schlüssel auf den Maschinen, solange die alten Zertifikate noch hereinkommen. Deshalb sind kurze Gültigkeiten ein Vorteil: Der Wechsel schließt sich von selbst ab.
Der private Schlüssel der CA wurde mir gestohlen
Wer ihn hat, kann Zertifikate für alle Ihre Maschinen signieren. Ersetzen Sie den öffentlichen Schlüssel auf allen so schnell wie möglich; haben Sie source-address genutzt, muss der Dieb zusätzlich an dieser IP sein. Das ist der Grund, ihn außerhalb der Maschinen und außerhalb der E-Mail aufzubewahren.
In Simplio
Simplio nutzt SSH-Zertifikate im Hintergrund, damit Sie es nicht tun müssen. Das Terminal im Browser meldet sich mit dem temporären Schlüssel an, den AWS für jede Sitzung ausgibt, ohne dass jemand eine Datei erhält. Und der Ersatzschlüssel ist genau das, was diese Anleitung erklärt, bis zum Äußersten getrieben: ein Benutzer ohne Passwort auf der Maschine, der nur von Simplio signierte Zertifikate akzeptiert, für fünf Minuten, für diesen Benutzer und nur von der IP von Simplio, mit Ihrem Zwei-Faktor-Code bei jeder Nutzung. Sie hinterlegen den Schlüssel mit einer Schaltfläche, und Simplio prüft jeden Tag, dass er noch öffnet. So funktioniert der Ersatzschlüssel.
Dasselbe, in AWS und in Simplio
| In der AWS-Konsole | In Simplio | |
|---|---|---|
| Einer Person Zugang geben | Ihren Schlüssel auf jede Maschine kopieren | Ihr die Maschine in Simplio zuweisen: Das Terminal im Browser nutzt den temporären Schlüssel, den AWS ausgibt |
| Ihn wieder entziehen | Ihren Schlüssel von jeder Maschine löschen, ohne eine zu vergessen | Ihr die Maschine in Simplio entziehen |
| Notfallzugang | Eigene CA erstellen, den öffentlichen Schlüssel verteilen, bei Bedarf von Hand ein Zertifikat signieren | Ersatzschlüssel: Zertifikat für fünf Minuten, von Simplio signiert, nur von seiner IP, mit Zwei-Faktor |
| Wissen, wer sich angemeldet hat | Das SSH-Protokoll jeder Maschine lesen | Aktivitätsprotokoll von Simplio: wer, welche Maschine, wann, von welcher IP |