Zwei Wege
Jedes Gerät, das sich mit einem Schlüssel verbindet, braucht einen privaten Schlüssel. Sie können jedem Gerät einen eigenen Schlüssel geben oder denselben Schlüssel auf alle kopieren.
| Ein Schlüssel pro Gerät | Ein kopierter Schlüssel | |
|---|---|---|
| Einrichtung | Jeden neuen öffentlichen Schlüssel auf jedem Server eintragen | Eine Datei auf jedes Gerät kopieren |
| Gerät verloren oder verkauft | Eine Zeile pro Server entfernen | Neuer Schlüssel auf jedem Gerät und jedem Server |
| Server-Logs | Zeigen, welches Gerät sich angemeldet hat | Alle Anmeldungen sehen gleich aus |
| Hardware-Schlüssel und Smartphones | Funktioniert, da der Schlüssel nie wandern muss | Nicht möglich, wenn der Schlüssel nicht exportierbar ist |
Ein Schlüssel pro Gerät ist die sicherere Grundeinstellung und die, die die meisten Teams nutzen. Kopieren lohnt sich bei wenigen Geräten, die Sie vollständig kontrollieren, wenn das Eintragen auf vielen Servern der größere Aufwand ist.
Schlüssel auf dem neuen Gerät erzeugen
Erzeugen Sie auf dem neuen Rechner einen Schlüssel mit einem Kommentar, der das Gerät benennt:
ssh-keygen -t ed25519 -C "me@desktop"Übernehmen Sie die vorgeschlagene Datei ~/.ssh/id_ed25519 und vergeben Sie eine Passphrase. Der Kommentar steht neben dem Schlüssel in authorized_keys und in Fingerprint-Listen, und genau damit finden Sie später die richtige Zeile zum Entfernen. Die Optionen erklärt die Anleitung Ed25519-SSH-Schlüssel erzeugen.
Auf Ihren Servern eintragen
Akzeptiert der Server noch Passwörter, führen Sie dies auf dem neuen Gerät aus:
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@serverIst die Passwort-Anmeldung abgeschaltet, was die bessere Einstellung ist, nehmen Sie ein Gerät, das sich schon anmelden kann. Bringen Sie die neue .pub-Datei dorthin (sie ist öffentlich, E-Mail oder Chat sind also in Ordnung) und hängen Sie sie an:
ssh deploy@server "cat >> ~/.ssh/authorized_keys" < desktop.pubPrüfen Sie, dass beide Schlüssel mit ihrem Kommentar vorhanden sind:
ssh deploy@server "ssh-keygen -lf ~/.ssh/authorized_keys"256 SHA256:l1AS4F9VRH90JA6uJuQw7/3uRDzrtMafpkeiO7zel84 me@laptop (ED25519)
256 SHA256:LGklWc72FhPwm7in/sLr3pGRujcSZ6a6z4E97qJGkRE me@desktop (ED25519)Wiederholen Sie das für jeden Server, und tragen Sie den Schlüssel bei GitHub oder GitLab unter den SSH-Schlüsseln des Kontos ein, wenn Sie von diesem Gerät Code pushen. Bei vielen Servern spart eine kurze Schleife über Ihre Host-Liste Zeit. Das Dateiformat erklärt die authorized_keys-Datei erklärt.
Wenn Sie den Schlüssel doch kopieren
Kopieren Sie beide Dateien, id_ed25519 und id_ed25519.pub, über einen Ende-zu-Ende verschlüsselten Weg: einen verschlüsselten USB-Stick, AirDrop oder scp zwischen zwei eigenen Rechnern. Meiden Sie E-Mail, Chat und geteilte Ordner, die Kopien behalten. Dann auf dem neuen Gerät:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pubOhne diese Rechte lehnt ssh den Schlüssel ab. Hat der Schlüssel keine Passphrase, vergeben Sie jetzt eine, denn er liegt nun an mehr Orten:
ssh-keygen -p -f ~/.ssh/id_ed25519Um zu prüfen, ob privater und öffentlicher Schlüssel zusammengehören, lassen Sie den öffentlichen Teil aus dem privaten ausgeben und vergleichen:
ssh-keygen -y -f ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pubBeide Zeilen müssen mit demselben Schlüssel beginnen. Mehr dazu in öffentlichen Schlüssel aus dem privaten Schlüssel gewinnen.
Wenn ein Gerät verloren geht oder ersetzt wird
Bei einem Schlüssel pro Gerät entfernen Sie die Zeile dieses Geräts auf jedem Server. Sichern Sie die Datei, löschen Sie per Kommentar und listen Sie auf, was übrig ist:
sed -i.bak '/ me@desktop$/d' ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keysEinen Kommentar kann jeder ändern, der Zugriff hatte. Suchen Sie bei einem gestohlenen Gerät deshalb nach dem Fingerprint, wie in einen SSH-Schlüssel sperren beschrieben. Entfernen Sie den Schlüssel auch bei GitHub und ähnlichen Diensten.
Bei einem kopierten Schlüssel hat das verlorene Gerät denselben Schlüssel wie alle anderen. Erzeugen Sie einen neuen Schlüssel, tragen Sie ihn überall ein, entfernen Sie den alten öffentlichen Schlüssel von jedem Server und Dienst und kopieren Sie den neuen privaten Schlüssel auf die Geräte, die Sie noch haben. Bis dahin schützt nur die Passphrase den alten Schlüssel.
Die Konfiguration überall gleich halten
Die privaten Schlüssel unterscheiden sich pro Gerät, ~/.ssh/config kann aber identisch sein, solange jedes Gerät seinen Schlüssel gleich benennt:
Host *
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Host prod
HostName 203.0.113.10
User deployDie Konfiguration enthält keine Geheimnisse und kann daher in einem Dotfiles-Repository oder Sync-Ordner liegen. Halten Sie id_*-Dateien ohne .pub daraus fern. Host-Muster finden Sie in Beispiele für die SSH-Config-Datei, und einen SSH-Schlüsselmanager mit verschlüsseltem Vault, wenn Sie Schlüssel und Server lieber zusammen aufbewahren.
Fragen
Darf ich meinen privaten SSH-Schlüssel auf einen anderen Rechner kopieren?
Es funktioniert, und OpenSSH ist es egal, wo ein Schlüssel erzeugt wurde. Der Preis kommt am Ende: Gelangt eine Kopie nach außen oder geht ein Gerät verloren, muss der Schlüssel auf jedem Server und jedem Gerät ersetzt werden, das ihn hat.
Kann ich meinen .ssh-Ordner in Dropbox, iCloud oder ein Dotfiles-Repository legen?
Konfiguration und öffentliche Schlüssel ja, private Schlüssel nie. Ein Sync-Ordner oder die Git-Historie behält Kopien, die Sie nicht vollständig löschen können.
Wie viele Schlüssel passen in authorized_keys?
Praktisch unbegrenzt viele. Jede Zeile ist ein Schlüssel, und ein Kommentar wie me@laptop am Ende unterscheidet sie.
Quellen
- ssh-keygen(1), OpenBSD-Handbuch
- sshd(8), AUTHORIZED_KEYS FILE FORMAT
- ssh-copy-id(1), Debian 13
- Adding a new SSH key to your GitHub account, GitHub Docs