So fügen Sie SSH-Schlüssel zu einem neuen oder vorhandenen VPS hinzu

SSH-Schlüssel sind kryptografische Schlüsselpaare — ein öffentlicher Schlüssel, der auf dem Server gespeichert wird, und ein privater Schlüssel, der auf Ihrem lokalen Rechner verbleibt — die Ihre Identität authentifizieren, ohne ein Passwort über das Netzwerk zu übertragen. Wenn Sie sich verbinden, stellt der Server eine kryptografische Herausforderung aus, die nur Ihr privater Schlüssel lösen kann, und gewährt Zugang, wenn die Antwort gültig ist. Dieser Mechanismus macht die SSH-Schlüsselauthentifizierung grundlegend widerstandsfähiger gegen Brute-Force-Angriffe, Credential Stuffing und Man-in-the-Middle-Abfangen als jedes passwortbasierte Verfahren.

Dieser Leitfaden behandelt den vollständigen Prozess der Generierung, Bereitstellung und Absicherung der SSH-Schlüsselauthentifizierung auf neuen und bestehenden VPS-Instanzen — einschließlich Sonderfälle, Berechtigungsfallen und Multi-Schlüssel-Verwaltung, die die meisten Tutorials vollständig auslassen.

Warum SSH-Schlüssel architektonisch überlegen gegenüber Passwörtern sind

Die Passwortauthentifizierung sendet ein Geheimnis (oder dessen Hash) über die Leitung und verlässt sich darauf, dass der Server eine überprüfbare Anmeldeinformation speichert. Die SSH-Public-Key-Authentifizierung legt den privaten Schlüssel niemals offen — nicht während der Generierung, nicht beim Login, niemals. Der private Schlüssel verlässt Ihren lokalen Rechner nie.

Über die reine Sicherheit hinaus erschließen SSH-Schlüssel betriebliche Möglichkeiten, die Passwörter nicht bieten können:

• Unbeaufsichtigte Automatisierung — CI/CD-Pipelines, Ansible-Playbooks und cron-gesteuerte rsync-Jobs erfordern nicht-interaktive Authentifizierung. Passwörter machen dies vollständig unmöglich.
• Granulare Zugangskontrolle — Jeder authorized_keys-Eintrag kann command=-, from=– und no-pty-Einschränkungen tragen und genau begrenzen, was ein bestimmter Schlüssel tun darf.
• Nachvollziehbarkeit — Einzelne Schlüssel können widerrufen werden, ohne ein gemeinsames Passwort zu ändern und jeden anderen Benutzer oder jedes Skript zu stören.
• Widerstandsfähigkeit gegen Phishing — Es gibt kein Passwort, das über eine gefälschte Anmeldeseite gestohlen werden könnte.

Voraussetzungen

Bestätigen Sie vor dem Fortfahren Folgendes:

• Sie haben einen laufenden VPS oder befinden sich gerade in der Bereitstellung eines solchen.
• Ihr lokaler Rechner läuft unter Linux, macOS oder Windows mit installiertem OpenSSH (Windows 10/11 wird standardmäßig mit OpenSSH geliefert; überprüfen Sie dies mit ssh -V).
• Sie haben Root- oder sudo-Zugang zum Zielserver.
• Sie verstehen, dass der Verlust Ihres privaten Schlüssels ohne eine alternative Anmeldemethode (Konsolenzugang, Wiederherstellungsschlüssel) Sie dauerhaft aussperren kann.

Den richtigen Schlüsselalgorithmus wählen

Der ursprüngliche ssh-keygen -t rsa -b 4096-Befehl ist solide, aber nicht die einzige Option. Das Verständnis der Kompromisse hilft Ihnen, die richtige Wahl für Ihre Umgebung zu treffen.

Ed25519 ist der empfohlene Algorithmus für jeden Server, der OpenSSH 6.5 oder höher ausführt (veröffentlicht 2014). Verwenden Sie RSA 4096 nur, wenn Sie sich mit Legacy-Systemen verbinden, die keine Elliptische-Kurven-Schlüssel unterstützen.

Teil 1: SSH-Schlüssel zu einem neuen VPS hinzufügen

Viele Hosting-Kontrollpanels ermöglichen es Ihnen, einen öffentlichen Schlüssel zum Bereitstellungszeitpunkt einzufügen, bevor die Instanz überhaupt startet. Dies ist der sauberste Ansatz — der Schlüssel wird in das Image eingebettet und die Passwortauthentifizierung muss möglicherweise nie aktiviert werden.

Schritt 1: Ihr SSH-Schlüsselpaar generieren

Öffnen Sie ein Terminal auf Ihrem lokalen Rechner. Generieren Sie ein Ed25519-Schlüsselpaar:

ssh-keygen -t ed25519 -C "your_email@example.com"

Wenn Sie RSA aus Kompatibilitätsgründen benötigen:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Wenn Sie nach einem Dateispeicherort gefragt werden, drücken Sie Enter, um den Standard zu akzeptieren (~/.ssh/id_ed25519 oder ~/.ssh/id_rsa). Wenn Sie nach einer Passphrase gefragt werden, legen Sie eine fest — sie verschlüsselt den privaten Schlüssel auf der Festplatte, sodass der Schlüssel selbst bei Diebstahl Ihres Laptops ohne die Passphrase nutzlos ist. Ihr SSH-Agent (ssh-agent) speichert den entschlüsselten Schlüssel im Arbeitsspeicher, sodass Sie die Passphrase nur einmal pro Sitzung eingeben müssen.

Überprüfen Sie die generierten Dateien:

ls -la ~/.ssh/

Sie werden sehen:

• id_ed25519 — Ihr privater Schlüssel (Berechtigungen müssen 600 sein; teilen Sie diese Datei niemals)
• id_ed25519.pub — Ihr öffentlicher Schlüssel (sicher, ihn überall zu kopieren)

Zeigen Sie den öffentlichen Schlüssel an, um ihn zu kopieren:

cat ~/.ssh/id_ed25519.pub

Die Ausgabe sieht so aus:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Kopieren Sie diese gesamte Zeichenkette — Sie werden sie in Ihr Hosting-Panel einfügen.

Schritt 2: Den öffentlichen Schlüssel während der VPS-Bereitstellung hinzufügen

Melden Sie sich in Ihrem Hosting-Kontrollpanel an. Während des VPS-Erstellungsworkflows:

1. Wählen Sie Ihr Betriebssystem (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 usw.).
2. Suchen Sie den Abschnitt SSH-Schlüssel oder Authentifizierung.
3. Fügen Sie den vollständigen Inhalt von id_ed25519.pub in das vorgesehene Feld ein.
4. Schließen Sie die verbleibende Konfiguration ab (Plan, Region, Hostname).

Sobald der VPS startet, schreibt das Bereitstellungssystem Ihren öffentlichen Schlüssel automatisch in /root/.ssh/authorized_keys. Es ist kein Passwort-Login erforderlich.

Schritt 3: Mit dem neu bereitgestellten VPS verbinden

ssh root@your_vps_ip

Wenn Sie einen nicht standardmäßigen Schlüsseldateinamen verwendet haben, geben Sie ihn explizit an:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Eine erfolgreiche Verbindung ohne Passwortaufforderung bestätigt, dass der Schlüssel korrekt eingefügt wurde. Wenn Sie eine Passphrase festgelegt haben, wird diese lokal von Ihrem SSH-Agent oder einer Passphrasenaufforderung verarbeitet.

Teil 2: SSH-Schlüssel zu einem bestehenden VPS hinzufügen

Wenn Ihr VPS bereits mit Passwortauthentifizierung läuft, müssen Sie den öffentlichen Schlüssel manuell bereitstellen. Dies ist ein zweiphasiger Prozess: den Schlüssel kopieren und dann optional den SSH-Daemon absichern.

Schritt 1: Ein Schlüsselpaar generieren (falls Sie noch keines haben)

Folgen Sie demselben Prozess wie in Schritt 1 in Teil 1 oben. Wenn Sie bereits ein Schlüsselpaar haben, rufen Sie Ihren öffentlichen Schlüssel ab:

cat ~/.ssh/id_ed25519.pub

Schritt 2: Den öffentlichen Schlüssel auf den Server kopieren

Methode A — ssh-copy-id (Empfohlen)

Das Dienstprogramm ssh-copy-id übernimmt automatisch die Verzeichniserstellung, das Anhängen von Dateien und das Setzen von Berechtigungen:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Geben Sie Ihr Passwort ein, wenn Sie dazu aufgefordert werden. Das Tool hängt den Schlüssel an ~/.ssh/authorized_keys auf dem Remote-Server an und setzt korrekte Berechtigungen. Dies ist die sicherste Methode, da sie versehentliches Überschreiben vorhandener Schlüssel verhindert.

Methode B — Manuelle Bereitstellung

Verwenden Sie diese Methode, wenn ssh-copy-id nicht verfügbar ist (z. B. in einigen Windows-Umgebungen oder eingeschränkten Netzwerken):

cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Diese einzelne Pipeline ist sicherer als das Öffnen eines Texteditors auf dem Remote-Server, da sie anhängt statt zu überschreiben.

Methode C — Manuell über Texteditor (Fallback)

Melden Sie sich mit Ihrem Passwort beim Server an:

ssh root@your_vps_ip

Erstellen Sie das .ssh-Verzeichnis, falls es nicht existiert:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Öffnen Sie authorized_keys in einem Texteditor:

nano ~/.ssh/authorized_keys

Fügen Sie Ihren öffentlichen Schlüssel in einer neuen Zeile ein. Speichern Sie mit Ctrl+X, dann Y, dann Enter. Berechtigungen setzen:

chmod 600 ~/.ssh/authorized_keys

Beenden Sie die Sitzung:

exit

Schritt 3: Schlüsselbasiertes Login überprüfen

Testen Sie die Verbindung bevor Sie weitere Änderungen am SSH-Daemon vornehmen. Öffnen Sie ein neues Terminalfenster (schließen Sie Ihre bestehende Sitzung noch nicht):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Wenn Sie sich ohne Passwortaufforderung verbinden, funktioniert der Schlüssel. Fahren Sie erst nach Bestätigung mit den nachfolgenden Absicherungsschritten fort.

Kritische Falle: Wenn Sie die Passwortauthentifizierung deaktivieren, bevor Sie den Schlüsselzugang überprüft haben, und die Schlüsselbereitstellung aus irgendeinem Grund fehlgeschlagen ist, sperren Sie sich selbst aus. Testen Sie immer zuerst.

Schritt 4: Die SSH-Daemon-Konfiguration absichern

Sobald der schlüsselbasierte Zugang bestätigt ist, öffnen Sie die SSH-Daemon-Konfigurationsdatei:

nano /etc/ssh/sshd_config

Wenden Sie die folgenden Einstellungen an:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Wichtige Hinweise zu diesen Direktiven:

• PermitRootLogin prohibit-password erlaubt Root-Login per Schlüssel, blockiert aber Root-Passwort-Login — ein besserer Mittelweg als PermitRootLogin no, wenn Sie noch einen Nicht-Root-sudo-Benutzer einrichten.
• ChallengeResponseAuthentication no deaktiviert die Tastatur-interaktive Authentifizierung, die PasswordAuthentication no bei einigen PAM-Konfigurationen umgehen kann.
• Unter Ubuntu 22.04+ kann die Datei /etc/ssh/sshd_config.d/50-cloud-init.conf Ihre Einstellungen überschreiben. Überprüfen und bearbeiten Sie sie bei Bedarf.

Überprüfen Sie die Konfigurationssyntax vor dem Neustart:

sshd -t

Wenn keine Fehler gemeldet werden, starten Sie den SSH-Dienst neu:

systemctl restart sshd

Auf Systemen, die ssh.service anstelle von sshd.service verwenden:

systemctl restart ssh

Verwaltung mehrerer SSH-Schlüssel und Benutzer

Reale Umgebungen umfassen selten nur einen einzigen Schlüssel und einen einzigen Benutzer. So gehen Sie mit komplexeren Szenarien um.

Schlüssel für mehrere Benutzer hinzufügen

Jedes Benutzerkonto hat seine eigene ~/.ssh/authorized_keys-Datei. Um einen Schlüssel für einen Nicht-Root-Benutzer namens deploy hinzuzufügen:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Der chown-Schritt wird häufig vergessen und verursacht Authentifizierungsfehler — SELinux und OpenSSH überprüfen beide, dass die authorized_keys-Datei dem authentifizierenden Benutzer gehört.

Einschränken, was ein Schlüssel tun kann

Sie können jeder Zeile in authorized_keys Optionen voranstellen, um deren Fähigkeiten zu begrenzen. Dies ist besonders nützlich für Deployment-Schlüssel oder Backup-Automatisierung:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Dieser Schlüssel kann nur rsync im Daemon-Modus ausführen — nichts anderes.

~/.ssh/config für sauberere Verbindungen verwenden

Anstatt lange ssh-Befehle einzutippen, definieren Sie Host-Aliase auf Ihrem lokalen Rechner:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Nach dem Speichern in ~/.ssh/config verbinden Sie sich einfach mit:

ssh myserver

ssh-agent zum Zwischenspeichern von Passphrasen verwenden

Wenn Ihr privater Schlüssel eine Passphrase hat (was er sollte), fügen Sie ihn dem Agent hinzu, damit Sie nicht wiederholt danach gefragt werden:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Unter macOS fügen Sie --apple-use-keychain hinzu, um über Neustarts hinweg zu persistieren:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Häufige Fallstricke und Fehlerbehebung

Problem: Nach dem Hinzufügen des Schlüssels wird weiterhin nach einem Passwort gefragt

Führen Sie die Verbindung mit ausführlicher Ausgabe zur Diagnose aus:

ssh -vvv root@your_vps_ip

Suchen Sie nach Zeilen wie Offering public key und Server accepts key. Wenn der Schlüssel angeboten, aber abgelehnt wird, liegt das Problem fast immer an den Dateiberechtigungen auf dem Server.

Überprüfen Sie die Berechtigungen auf dem Server:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Erforderliche Berechtigungen:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Home-Verzeichnis ~/ — darf nicht für alle beschreibbar sein (755 oder 750)

Problem: SELinux blockiert Authentifizierung auf RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Problem: authorized_keys-Datei hat Windows-Zeilenenden (CRLF)

Wenn Sie die Datei unter Windows bearbeitet und übertragen haben, können die Zeilenenden beschädigt sein. Beheben Sie dies mit:

sed -i 's/r//' ~/.ssh/authorized_keys

Problem: Falscher Schlüssel wird angeboten

Wenn Sie mehrere Schlüssel haben, geben Sie den richtigen explizit an:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Oder konfigurieren Sie es in ~/.ssh/config wie oben gezeigt.

SSH-Schlüssel im Kontext Ihrer Hosting-Infrastruktur

SSH-Schlüsselauthentifizierung ist nicht nur ein Einzelserver-Anliegen — sie skaliert über Ihre gesamte Infrastruktur. Wenn Sie eine Flotte von dedizierten Servern verwalten, ist ein zentralisierter Ansatz mit Tools wie Ansible, Puppet oder einem Secrets-Manager (HashiCorp Vault, AWS Secrets Manager) zur Verteilung und Rotation autorisierter Schlüssel unerlässlich.

Für Teams, die Webanwendungen auf VPS mit cPanel betreiben, bietet die SSH-Zugang-Oberfläche von cPanel im Sicherheitsbereich eine GUI zur Generierung und Verwaltung von Schlüsselpaaren — nützlich für Entwickler, die sich mit der Befehlszeile nicht wohlfühlen, aber dennoch sicheren Zugang benötigen.

Wenn Sie GPU-intensive Workloads auf GPU-Hosting-Infrastruktur betreiben, ist die SSH-Schlüsselauthentifizierung besonders kritisch, da diese Instanzen oft langlebige, unbeaufsichtigte Jobs ausführen. Eine kompromittierte Anmeldeinformation auf einem GPU-Server kann neben der Datenoffenlegung zu erheblichen unbefugten Rechenkosten führen.

Die Kombination von SSH-Absicherung mit einem gültigen SSL-Zertifikat für alle webbasierten Dienste, die auf demselben Server laufen, schließt gleichzeitig die beiden häufigsten Angriffsvektoren — nicht authentifizierten Shell-Zugang und unverschlüsselten HTTP-Verkehr.

Für Projekte, die Shared Web Hosting nutzen und auch SSH-Zugang benötigen, prüfen Sie, ob Ihr Anbieter SSH-Schlüsselinjektion über das Hosting-Panel unterstützt, da gemeinsam genutzte Umgebungen SSH oft auf bestimmte Benutzer mit eingeschränktem Shell-Zugang beschränken.

Schlüsselrotation und langfristige Schlüsselverwaltung

SSH-Schlüssel laufen nicht automatisch ab. Ohne eine Rotationsrichtlinie kann ein vor Jahren kompromittierter Schlüssel immer noch Zugang gewähren. Etablieren Sie diese Praktiken:

• Schlüssel jährlich rotieren oder sofort bei Verdacht auf Kompromittierung.
• authorized_keys-Dateien regelmäßig prüfen auf allen Servern. Entfernen Sie Schlüssel ehemaliger Mitarbeiter oder stillgelegter Dienste.
• Separate Schlüssel pro Gerät verwenden — kopieren Sie nicht denselben privaten Schlüssel auf mehrere Laptops oder Server. Wenn ein Gerät verloren geht, widerrufen Sie nur diesen Schlüssel.
• Separate Schlüssel pro Rolle verwenden — Ihr persönlicher Zugriffsschlüssel, Ihr CI/CD-Deployment-Schlüssel und Ihr Backup-Automatisierungsschlüssel sollten alle unterschiedlich sein.
• Schlüsseleigentümerschaft dokumentieren — führen Sie ein Register, das jeden öffentlichen Schlüssel-Fingerabdruck seinem Eigentümer, Zweck und Ablaufdatum zuordnet.

Um den Fingerabdruck eines Schlüssels für die Prüfung anzuzeigen:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Technische Entscheidungs-Checkliste

Verwenden Sie diese Matrix, bevor Sie Ihr SSH-Schlüssel-Setup abschließen:

• Algorithmus: Verwenden Sie Ed25519, es sei denn, Sie verbinden sich mit Systemen, die älter als OpenSSH 6.5 sind; verwenden Sie RSA 4096 als Fallback.
• Passphrase: Legen Sie immer eine für private Schlüssel fest, die von Menschen verwendet werden; Dienstschlüssel für die Automatisierung können darauf verzichten, wenn sie in einem Secrets-Manager gespeichert sind.
• Bereitstellungsmethode: Verwenden Sie ssh-copy-id für interaktive Setups; verwenden Sie Konfigurationsmanagement (Ansible, Puppet) für Fleet-Deployments.
• Berechtigungsüberprüfung: Bestätigen Sie 700 auf ~/.ssh/, 600 auf authorized_keys und korrekte Eigentümerschaft, bevor Sie die Passwortauthentifizierung deaktivieren.
• Vor der Sperrung testen: Überprüfen Sie immer den Schlüssel-Login in einer separaten Terminalsitzung, bevor Sie PasswordAuthentication no setzen.
• Daemon-Konfigurationsvalidierung: Führen Sie sshd -t aus, bevor Sie den SSH-Dienst neu starten, um Syntaxfehler zu erkennen.
• Passwortauthentifizierung deaktivieren: Setzen Sie PasswordAuthentication no und ChallengeResponseAuthentication no zusammen — eines allein ist auf PAM-fähigen Systemen unzureichend.
• Root-Login-Richtlinie: Bevorzugen Sie PermitRootLogin prohibit-password gegenüber PermitRootLogin yes; migrieren Sie zu einem Nicht-Root-sudo-Benutzer und setzen Sie PermitRootLogin no als endgültigen abgesicherten Zustand.
• Schlüsselrotation: Planen Sie eine jährliche Rotation; widerrufen Sie sofort bei Geräteverlust oder Personalwechsel.
• Prüfung: Führen Sie regelmäßig grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys aus, um alle autorisierten Schlüssel im System zu überprüfen.

FAQ

Kann ich mehrere SSH-Schlüssel zum selben Server hinzufügen?

Ja. Jede Zeile in ~/.ssh/authorized_keys repräsentiert einen autorisierten öffentlichen Schlüssel. Sie können so viele Schlüssel hinzufügen, wie benötigt — einen pro Zeile. Dies ermöglicht es mehreren Administratoren oder mehreren Geräten, sich unabhängig zu authentifizieren, und Sie können jeden einzelnen Schlüssel widerrufen, indem Sie seine Zeile löschen, ohne die anderen zu beeinträchtigen.

Was passiert, wenn ich meinen privaten Schlüssel verliere, nachdem ich die Passwortauthentifizierung deaktiviert habe?

Sie werden vom SSH-Zugang ausgesperrt. Die Wiederherstellung erfordert den Zugang zum Server über eine Out-of-Band-Methode: die Web-Konsole Ihres Hosting-Anbieters, VNC oder eine Rettungs-/Wiederherstellungs-Bootumgebung. Von dort aus können Sie die Passwortauthentifizierung wieder aktivieren oder einen neuen öffentlichen Schlüssel hinzufügen. Deshalb ist es wichtig, Konsolenzugangsdaten sicher und separat aufzubewahren.

Wird Ed25519 auf allen Servern unterstützt?

Ed25519 erfordert OpenSSH 6.5 oder höher, veröffentlicht im Januar 2014. Jeder Server, der eine moderne Linux-Distribution ausführt (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+), unterstützt es. Das einzige Szenario, das RSA erfordert, ist die Verbindung zu echten Legacy-Systemen oder eingebetteten Geräten mit veralteten OpenSSH-Builds.

Deaktiviert das Hinzufügen eines SSH-Schlüssels automatisch den Passwort-Login?

Nein. Das Hinzufügen eines Schlüssels zu authorized_keys aktiviert den schlüsselbasierten Login, deaktiviert aber nicht die Passwortauthentifizierung. Sie müssen explizit PasswordAuthentication no in /etc/ssh/sshd_config setzen und den SSH-Daemon neu starten, um ausschließlich schlüsselbasierten Zugang zu erzwingen.

Kann ich dasselbe SSH-Schlüsselpaar für mehrere Server verwenden?

Technisch ja, aber es wird für Produktionsumgebungen nicht empfohlen. Die Verwendung eines einzigen Schlüssels auf vielen Servern bedeutet, dass die Kompromittierung eines privaten Schlüssels Zugang zu allen gewährt. Die bessere Praxis ist die Verwendung gerätespezifischer Schlüssel (ein Schlüssel pro Workstation oder Laptop), sodass der Verlust eines Geräts nur den Widerruf dieses Schlüssels in Ihrer Server-Flotte erfordert, anstatt überall gleichzeitig Schlüssel zu ersetzen.