Jemand muss heute Abend auf einen Server, und die Zugangsdaten müssen jetzt bei ihm ankommen. Die Versuchung ist groß, den privaten Schlüssel oder das Root-Passwort in Slack einzufügen. Jede Nachricht, durch die dieser Schlüssel geht, behält eine Kopie. Deshalb ist ein Einmal-Link, der abläuft, der bessere Weg: Die vertrauliche Information wird einmal abgerufen und ist dann weg.
Der Link ist allerdings nur der Zustellschritt. Bevor Sie einen erstellen, wählen Sie die richtigen Zugangsdaten, schränken Sie sie auf die Aufgabe ein und legen Sie fest, wie Sie sie wieder entfernen. Dieser Leitfaden behandelt all das, auch die Frage, was in einen Einmal-Link für Serverzugangsdaten gehört und was nicht.
Welche SSH-Zugangsdaten teilen Sie eigentlich?
SSH-Zugriff kann auf vier verschiedenen Dingen beruhen, und für sie gelten beim Teilen sehr unterschiedliche Regeln.
| Zugangsdaten | Was das ist | Darf das überhaupt übertragen werden? |
|---|---|---|
| Öffentlicher Schlüssel | Die Hälfte, die der Server speichert | Ja, ohne Bedenken. Er ist nicht geheim. |
| Privater Schlüssel | Die Hälfte, die der Nutzer besitzt | Nur wenn er für den Empfänger erzeugt wurde, und nur einmal |
| Passwort | Eine gemeinsame Zeichenfolge, die der Server prüft | Einmal, als vorläufiger Wert, den Sie ändern werden |
| SSH-Zertifikat | Ein von Ihrer CA signierter Schlüssel mit Gültigkeitsdauer | Das Zertifikat ist nicht geheim, der Schlüssel dahinter schon |
Die beste Übergabe ist eine, bei der nichts Geheimes übertragen wird. Hat der
Empfänger bereits ein SSH-Schlüsselpaar, bitten Sie um seinen öffentlichen Schlüssel, tragen Sie
ihn beim richtigen Konto in ~/.ssh/authorized_keys ein und sagen Sie ihm, dass er sich
verbinden kann. Entfernen Sie diese eine Zeile später, endet sein Zugriff.
Erzeugen Sie eigens für ihn einen Schlüssel, wenn er keinen hat und keinen erstellen kann. Senden Sie nie den privaten Schlüssel, den Sie selbst täglich nutzen. Einen Schlüssel, der für den Empfänger erzeugt wurde, können Sie einschränken, protokollieren und löschen, ohne etwas anderes anzufassen.
Setzen Sie bei wiederkehrendem Bedarf auf Zertifikate oder verwalteten Zugriff. Braucht dieselbe Person immer wieder Zugriff, sind wiederholte Einmal-Übergaben das falsche Werkzeug. Ein SSH-Zertifikat mit kurzer Gültigkeit oder ein Zugriffstool wie Teleport oder Tailscale SSH bringt den Ablauf direkt in den Zugangsdaten mit, statt ihn nachträglich an die Zustellung anzuhängen.
Schränken Sie die Zugangsdaten vor dem Teilen ein
Was auch immer Sie senden, halten Sie es so klein, wie die Aufgabe es erlaubt:
- Ein Konto, ein Host. Tragen Sie den Schlüssel beim Dienstkonto ein, dem die Arbeit gehört, nicht bei root, und nur auf der betroffenen Maschine.
- Begrenzen Sie, was der Schlüssel darf, mit Optionen in
authorized_keyswiefrom="203.0.113.5",no-port-forwardingoder einemcommand=-Wrapper, wenn die Aufgabe aus einem einzigen Skript besteht. - Geben Sie dem Passwort ein Verfallsdatum. Wenn Sie ein Passwort teilen,
führen Sie
passwd -eoder das Gegenstück Ihrer Plattform aus. Dann muss der Empfänger es bei der ersten Anmeldung ändern. Legen Sie ein festes Datum fest, an dem Sie das Konto deaktivieren. - Schreiben Sie das Enddatum auf, bevor Sie irgendetwas senden. „Wenn die Arbeit erledigt ist“ ist kein Datum.
So teilen Sie SSH-Zugangsdaten mit einem ablaufenden Link
- Bestätigen Sie den Empfänger über einen Kanal, dem Sie bereits vertrauen: das Ticket, einen bekannten E-Mail-Verlauf oder ein Telefonat. Die meisten fehlgeleiteten Zugangsdaten gehen auf eine täuschend ähnliche Adresse oder einen automatisch ergänzten Namen zurück.
- Fügen Sie nur das Geheimnis in das Tool für Einmal-Links ein. Bei einem privaten Schlüssel heißt das: den kompletten PEM-Block und sonst nichts. Bei LinkPilot wird der Text in Ihrem Browser verschlüsselt, bevor er gespeichert wird. Der Dienst hat also immer nur Geheimtext, und der Schlüssel zum Entschlüsseln steht in dem Teil der URL, den Browser nicht an Server senden.
- Stellen Sie den Ablauf passend zum Zeitfenster ein. Eine Stunde, wenn die Person darauf wartet, 24 Stunden, wenn sie in einer anderen Zeitzone ist, sieben Tage nur mit echtem Grund. Der Link wird außerdem beim ersten Öffnen vernichtet. Der Ablauf ist also die Rückfallebene, nicht die wichtigste Kontrolle.
- Fügen Sie mit einem Pro-Konto eine Passphrase hinzu, wenn die Zugangsdaten sensibel sind, und übermitteln Sie die Passphrase über einen anderen Kanal. Der Audit-Verlauf in Pro zeigt Ihnen außerdem, wann der Inhalt angezeigt wurde.
- Senden Sie den Link mit einer kurzen Notiz zum Zweck und ohne Verbindungsdaten.
- Senden Sie die Verbindungsdaten in einer separaten Nachricht: Host oder Adresse, Port, Benutzername und Authentifizierungsmethode. Keine dieser Angaben ist für sich geheim, aber zusammen mit dem Schlüssel ergeben sie das komplette Login.
Meldet der Link, dass er bereits geöffnet wurde, und der Empfänger sagt, er habe ihn nicht geöffnet, diskutieren Sie nicht. Behandeln Sie die Zugangsdaten als kompromittiert, entfernen Sie den Schlüssel oder ändern Sie das Passwort und erzeugen Sie neue Zugangsdaten.
Ein Einmal-Link für Serverzugangsdaten
Die Frage, was in das Geheimnis gehört, stellt sich jedes Mal. Eine gute Regel: Der Link enthält, was ein Angreifer nicht erraten könnte; die normale Nachricht enthält, was er erraten könnte.
Im Einmal-Link:
- Der private Schlüssel oder das vorläufige Passwort
- Eine Passphrase für den Schlüssel, falls beim Erzeugen eine gesetzt wurde
- Sonst nichts
In einer normalen Nachricht, getrennt gesendet:
- Hostname oder IP-Adresse und Port
- Das Konto, mit dem sich die Person anmeldet
- Ob ein Schlüssel oder ein Passwort verwendet wird
- Der Fingerabdruck des Host-Schlüssels, damit der Empfänger den Server bei der ersten Verbindung prüfen kann
- Eine kurze Notiz, wofür der Zugriff gedacht ist und wann er endet
Screenshots und Terminal-Logs gehören in keine der beiden. Ein Screenshot einer laufenden Sitzung enthält oft Tokens, interne Adressen und andere Benutzernamen, die nie weitergegeben werden sollten.
Helfen Sie dem Empfänger, den Schlüssel sicher abzulegen
Eine sichere Übergabe nützt nichts, wenn der Schlüssel im Download-Ordner landet und für alle lesbar ist. Senden Sie diese Anweisungen zusammen mit den Verbindungsdaten:
# save the key, then lock it down
chmod 600 ~/.ssh/acme_deploy
ssh-add ~/.ssh/acme_deploy
# verify the host key fingerprint against the one you were sent
ssh -i ~/.ssh/acme_deploy deploy@203.0.113.5
Bitten Sie die Person, den Secret-Link erst zu öffnen, wenn sie ihn sofort nutzen kann, auf einem Gerät, das sie selbst kontrolliert, und über eine Verbindung, der sie vertraut. Wer ihn auf einem gemeinsam genutzten Rechner öffnet, „um zu prüfen, ob es klappt“, hinterlässt eine Kopie im Verlauf der Zwischenablage dieses Rechners.
Prüfen, dann das Zeitfenster schließen
Solange das Zugriffsfenster noch offen ist, lassen Sie den Empfänger genau diese Verbindung testen und bestätigen, dass die Aufgabe läuft. Erweitern Sie die Rechte nicht, nur damit ein Test durchläuft. Korrigieren Sie stattdessen die Einschränkung.
Wenn die Arbeit erledigt ist:
- Entfernen Sie den öffentlichen Schlüssel aus
authorized_keys, deaktivieren Sie das Konto oder lassen Sie das Zertifikat planmäßig ablaufen. - Erneuern Sie alles, was mitgeschickt wurde, auch ein vorläufiges Passwort, das bei der ersten Anmeldung geändert werden sollte und nicht geändert wurde.
- Prüfen Sie
auth.logoder Ihre SSH-Audit-Quelle auf Verbindungen außerhalb der vereinbarten Zeit oder von unerwarteten Adressen. - Halten Sie fest, wer was von wann bis wann hatte. Die Aufzeichnung bleibt, die Zugangsdaten nicht.
Der Ablauf des Links begrenzt, wie lange sich die vertrauliche Information abrufen ließ. Der Ablauf der Zugangsdaten begrenzt, wie lange sie sich nutzen lassen. Sie brauchen beides, und das Zweite ist das, was gern vergessen wird.