Wie man einen öffentlichen SSH-Schlüssel auf einen bestehenden VPS hochlädt

Ein öffentlicher SSH-Schlüssel ist ein kryptografisches Anmeldedatum, das in ~/.ssh/authorized_keys auf einem Remote-Server gespeichert ist und jedem Client, der den entsprechenden privaten Schlüssel besitzt, Zugang gewährt — ohne ein Passwort über das Netzwerk zu übertragen. Das Hochladen Ihres öffentlichen Schlüssels auf einen bestehenden VPS ersetzt oder ergänzt die passwortbasierte Authentifizierung durch asymmetrische Kryptografie und eliminiert die Angriffsfläche, die von Brute-Force- und Credential-Stuffing-Kampagnen ausgenutzt wird.

Dieser Leitfaden behandelt jeden Schritt des Prozesses: Schlüsselgenerierung, manuelle und automatisierte Upload-Methoden, Berechtigungshärtung, sshd_config-Konfiguration, Verwaltung mehrerer Schlüssel und häufige Fehlerquellen, die selbst erfahrene Administratoren stolpern lassen.

Warum SSH-Schlüssel-Authentifizierung Passwörtern überlegen ist

Bevor Sie einen einzigen Befehl eingeben, lohnt es sich, die kryptografischen Mechanismen zu verstehen. Wenn Sie sich mit einem Schlüsselpaar authentifizieren, stellt der Server eine mit Ihrem öffentlichen Schlüssel verschlüsselte Herausforderung aus. Nur der Inhaber des passenden privaten Schlüssels kann die Antwort entschlüsseln und signieren. Es wird kein Geheimnis übertragen — im Gegensatz zur Passwortauthentifizierung, bei der das Anmeldedatum selbst über die Leitung übertragen wird (auch wenn es TLS-verschlüsselt ist).

Das praktische Fazit: In jeder VPS Hosting-Umgebung, die dem öffentlichen Internet ausgesetzt ist, sind SSH-Schlüssel keine optionale Härtungsmaßnahme — sie sind die Grundlage.

Voraussetzungen

• Ein bestehender VPS, der über SSH erreichbar ist (Passwort- oder bestehende Schlüsselanmeldung funktioniert derzeit)
• Ein lokaler Rechner mit Linux, macOS oder Windows mit OpenSSH oder PuTTY
• Ausreichende Berechtigungen auf dem VPS, um in das Home-Verzeichnis des Zielbenutzers zu schreiben
• Grundlegende Vertrautheit mit einem Terminal und einem Texteditor wie nano oder vim

Schritt 1: Ein SSH-Schlüsselpaar generieren

Wenn Sie bereits ein Schlüsselpaar unter ~/.ssh/id_ed25519 oder ~/.ssh/id_rsa haben, überspringen Sie diesen Abschnitt. Andernfalls generieren Sie jetzt eines.

Den richtigen Algorithmus wählen

Ed25519 ist der moderne Standard. Verwenden Sie RSA 4096 nur, wenn Sie sich mit Legacy-Servern verbinden, die Ed25519 nicht unterstützen.

Ein Ed25519-Schlüsselpaar generieren:

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

Ein RSA 4096-Schlüsselpaar generieren (Legacy-Systeme):

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

Während der Schlüsselgenerierung werden Sie nach einem Speicherpfad und einer optionalen Passphrase gefragt. Den Standardpfad (~/.ssh/id_ed25519) zu akzeptieren ist für die meisten Benutzer in Ordnung. Setzen Sie immer eine Passphrase — sie verschlüsselt den privaten Schlüssel auf der Festplatte mit AES-256, sodass ein gestohlener Laptop nicht automatisch einen kompromittierten Server bedeutet.

Der Prozess erzeugt zwei Dateien:

• ~/.ssh/id_ed25519 — Ihr privater Schlüssel. Teilen Sie diesen niemals, kopieren Sie ihn niemals auf einen Server, committen Sie ihn niemals in die Versionskontrolle.
• ~/.ssh/id_ed25519.pub — Ihr öffentlicher Schlüssel. Dieser kann frei verteilt werden.

Zeigen Sie den öffentlichen Schlüssel an, damit Sie ihn kopieren können:

cat ~/.ssh/id_ed25519.pub

Die Ausgabe sieht ähnlich aus wie:

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

Kopieren Sie die gesamte einzeilige Zeichenkette einschließlich des Algorithmus-Präfixes und des Kommentars am Ende.

Schritt 2: In Ihren VPS einloggen

Verbinden Sie sich mit dem VPS über Ihre aktuelle Authentifizierungsmethode:

ssh root@your_vps_ip

Ersetzen Sie your_vps_ip durch die tatsächliche IPv4- oder IPv6-Adresse Ihres Servers. Wenn Sie ein Nicht-Root-Benutzerkonto verwalten, ersetzen Sie root durch den entsprechenden Benutzernamen. Auf Dedicated Servers, auf denen Sie möglicherweise mehrere Benutzerkonten haben, bevorzugen Sie immer die Bereitstellung von Schlüsseln für einen Nicht-Root-Benutzer und verwenden sudo für die Rechteerweiterung.

Schritt 3: Das .ssh-Verzeichnis vorbereiten

Überprüfen oder erstellen Sie nach dem Einloggen das .ssh-Verzeichnis für den Zielbenutzer:

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

Die 700-Berechtigung (rwx------) ist obligatorisch. OpenSSH wird authorized_keys stillschweigend ablehnen, wenn das .ssh-Verzeichnis gruppen- oder weltschreibbar ist. Dies ist einer der häufigsten Gründe, warum die Schlüsselauthentifizierung nach einer ansonsten korrekten Einrichtung fehlschlägt.

Schritt 4: Den öffentlichen Schlüssel zu authorized_keys hinzufügen

Methode A: Manuelles Einfügen (Universal)

Öffnen oder erstellen Sie die authorized_keys-Datei:

nano ~/.ssh/authorized_keys

Fügen Sie Ihren öffentlichen Schlüssel in eine neue Zeile ein. Jede Zeile in dieser Datei repräsentiert einen autorisierten Schlüssel. Speichern Sie mit Ctrl+X, dann Y, dann Enter.

Setzen Sie die korrekten Berechtigungen:

chmod 600 ~/.ssh/authorized_keys

Die 600-Berechtigung (rw-------) stellt sicher, dass nur der Dateibesitzer sie lesen oder schreiben kann. OpenSSH erzwingt dies strikt.

Methode B: ssh-copy-id (Empfohlen für Geschwindigkeit)

Wenn Ihr lokaler Rechner ssh-copy-id verfügbar hat (Standard unter Linux und macOS), übernimmt dieser einzelne Befehl automatisch die Verzeichniserstellung, das Anhängen des Schlüssels und das Setzen der Berechtigungen:

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

Sie werden einmal nach dem aktuellen SSH-Passwort gefragt. Danach ist die schlüsselbasierte Anmeldung aktiv. Das -i-Flag gibt explizit an, welcher öffentliche Schlüssel hochgeladen werden soll, und verhindert versehentliche Uploads des falschen Schlüssels.

Methode C: Einzeiler über cat und Pipe (Skriptfähig)

Nützlich in Automatisierungs-Pipelines oder wenn ssh-copy-id nicht verfügbar ist:

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"

Dieser Ansatz ist idempotent-sicher in dem Sinne, dass er anhängt statt zu überschreiben und dabei vorhandene autorisierte Schlüssel bewahrt.

Schritt 5: Korrekte Dateibesitzer überprüfen

Eine häufig übersehene Falle: Wenn Sie das .ssh-Verzeichnis oder die authorized_keys-Datei als root erstellt haben, während Sie das Konto eines anderen Benutzers eingerichtet haben, ist der Besitz falsch und SSH wird den Schlüssel stillschweigend ablehnen.

Besitz prüfen:

ls -la ~/.ssh/

Die Ausgabe sollte den Zielbenutzernamen sowohl als Besitzer als auch als Gruppe für das Verzeichnis und die Datei anzeigen:

drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys

Wenn der Besitz falsch ist, korrigieren Sie ihn (als Root ausführen):

chown -R alice:alice /home/alice/.ssh

Schritt 6: Die SSH-Schlüsselanmeldung testen

Beenden Sie die aktuelle Sitzung:

exit

Verbinden Sie sich erneut mit expliziter Schlüsselangabe, um die Einrichtung zu bestätigen:

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

Wenn die Anmeldung ohne Passwortabfrage gelingt (oder nur nach Ihrer lokalen Schlüssel-Passphrase fragt), ist die Konfiguration korrekt. Wenn weiterhin nach dem Server-Passwort gefragt wird, fahren Sie mit dem Abschnitt zur Fehlerbehebung unten fort.

Schritt 7: Die SSH-Daemon-Konfiguration härten

Sobald die schlüsselbasierte Anmeldung bestätigt funktioniert, deaktivieren Sie die Passwortauthentifizierung, um den Passwort-Brute-Force-Angriffsvektor vollständig zu eliminieren.

Öffnen Sie die SSH-Daemon-Konfigurationsdatei:

nano /etc/ssh/sshd_config

Suchen und setzen Sie die folgenden Direktiven. Wenn eine Zeile mit # auskommentiert ist, entfernen Sie das # und setzen Sie den Wert:

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

Ein Hinweis zu PermitRootLogin prohibit-password: Diese Einstellung erlaubt Root-Anmeldungen ausschließlich über Schlüssel, blockiert passwortbasierten Root-Zugriff und erlaubt gleichzeitig schlüsselauthentifizierte Root-Sitzungen. Für maximale Härtung setzen Sie es auf no und verwenden Sie einen Nicht-Root-Benutzer mit sudo.

Auf einigen Distributionen kann eine sekundäre Konfigurationsdatei Ihre Einstellungen überschreiben. Prüfen Sie auf Überschreibungen:

grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/

Wenn eine Datei in diesem Verzeichnis PasswordAuthentication yes setzt, bearbeiten oder entfernen Sie sie.

Überprüfen Sie die Konfigurationssyntax vor dem Neustart:

sshd -t

Eine saubere Ausgabe (keine Fehler) bedeutet, dass ein Neuladen sicher ist. Wenden Sie die Änderungen an:

systemctl restart sshd

Kritische Warnung: Schließen Sie Ihre bestehende SSH-Sitzung nicht, bevor Sie ein zweites Terminal öffnen und bestätigen, dass Sie sich noch mit Ihrem Schlüssel anmelden können. Das Neustarten von sshd mit einer falsch konfigurierten Datei oder bevor Ihr Schlüssel funktioniert, sperrt Sie aus. Die meisten VPS Control Panels bieten eine Notfallkonsole (KVM/VNC-Zugang) zur Wiederherstellung, aber es ist weit besser, die Situation ganz zu vermeiden.

Schritt 8: Mehrere Schlüssel und Server mit ~/.ssh/config verwalten

Bei der Verwaltung mehrerer Server — üblich in Staging-/Produktionsumgebungen oder bei der Administration mehrerer Dedicated Servers — eliminiert die SSH-Client-Konfigurationsdatei die Notwendigkeit, sich IP-Adressen, Benutzernamen und Schlüsselpfade zu merken.

Erstellen oder bearbeiten Sie ~/.ssh/config auf Ihrem lokalen Rechner:

nano ~/.ssh/config

Beispielkonfiguration für mehrere Hosts:

Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa

Setzen Sie korrekte Berechtigungen für die Konfigurationsdatei:

chmod 600 ~/.ssh/config

Sie können sich jetzt mit sauberen Aliasen verbinden:

ssh production-vps
ssh staging-vps

Die PubkeyAcceptedKeyTypes +ssh-rsa-Direktive beim Legacy-Eintrag ist wichtig: Neuere OpenSSH-Clients (8.8+) deaktivieren RSA-SHA1 standardmäßig. Ohne diese Überschreibung schlagen Verbindungen zu älteren Servern mit einem kryptischen Fehler „no matching host key type” fehl.

Fehlerbehebung: Warum SSH-Schlüssel-Authentifizierung fehlschlägt

Selbst bei einer korrekten Einrichtung können mehrere Umgebungsfaktoren dazu führen, dass die Schlüsselauthentifizierung stillschweigend auf Passwortabfragen zurückfällt:

Falsche Berechtigungen für .ssh oder authorized_keys:

Führen Sie ls -la ~/.ssh/ auf dem Server aus. Das Verzeichnis muss 700 und die Datei muss 600 sein. Jede lockerere Berechtigung führt dazu, dass OpenSSH die Datei ignoriert.

SELinux- oder AppArmor-Kontextfehler:

Auf RHEL/CentOS/AlmaLinux-Systemen mit aktiviertem SELinux kann die authorized_keys-Datei den falschen Sicherheitskontext haben. Stellen Sie ihn wieder her mit:

restorecon -Rv ~/.ssh

Falsches Home-Verzeichnis des Benutzers:

Wenn das Home-Verzeichnis des Benutzers nicht nur vom Besitzer beschreibbar ist, verweigert SSH die Schlüsselauthentifizierung. Prüfen Sie mit:

ls -ld ~

Das Home-Verzeichnis selbst darf nicht gruppen- oder weltschreibbar sein.

AuthorizedKeysFile-Direktive zeigt woanders hin:

Einige Distributionen konfigurieren AuthorizedKeysFile so, dass ein nicht standardmäßiger Pfad verwendet wird (z. B. /etc/ssh/authorized_keys/%u). Überprüfen Sie die aktive Einstellung:

sshd -T | grep authorizedkeysfile

Mehrere Schlüssel und ssh-agent-Konflikte:

Wenn ssh-agent mit mehreren geladenen Schlüsseln läuft, kann der Server die Verbindung nach zu vielen fehlgeschlagenen Schlüsselversuchen ablehnen, bevor der richtige versucht wird. Verwenden Sie -i, um den Schlüssel explizit anzugeben, oder konfigurieren Sie IdentitiesOnly yes in ~/.ssh/config.

Firewall oder fail2ban blockiert Ihre IP:

Wenn Sie zuvor mehrere fehlgeschlagene Anmeldeversuche hatten, können fail2ban– oder ufw/iptables-Regeln Ihre IP vorübergehend gesperrt haben. Prüfen Sie mit:

fail2ban-client status sshd

SSH-Schlüssel rotieren und widerrufen

Die Schlüsselrotation ist eine Sicherheitshygiene-Praxis, die oft vernachlässigt wird. Um einen bestimmten Schlüssel zu widerrufen, öffnen Sie ~/.ssh/authorized_keys auf dem Server und löschen Sie die entsprechende Zeile. Jede Zeile ist ein Schlüssel — das Entfernen widerruft sofort den Zugang für den Inhaber dieses privaten Schlüssels, ohne andere autorisierte Schlüssel zu beeinflussen.

Verwenden Sie für Prüfzwecke eindeutige Kommentare bei jedem Schlüssel (der Teil nach dem Schlüsselmaterial, z. B. alice@workstation-2024), damit Sie erkennen können, welcher Schlüssel zu welcher Person oder welchem Gerät gehört. Wenn ein Mitarbeiter das Unternehmen verlässt oder ein Gerät außer Betrieb genommen wird, suchen Sie seinen Schlüssel anhand des Kommentars und entfernen Sie ihn.

Um Ihren eigenen Schlüssel zu rotieren, generieren Sie ein neues Paar, fügen Sie den neuen öffentlichen Schlüssel zu authorized_keys hinzu, überprüfen Sie, ob die Anmeldung mit dem neuen Schlüssel funktioniert, und entfernen Sie dann den alten Schlüsseleintrag.

Praktische Checkliste der wichtigsten Punkte

• Generieren Sie standardmäßig Ed25519-Schlüssel; verwenden Sie RSA 4096 nur für Legacy-Server-Kompatibilität
• Schützen Sie Ihren privaten Schlüssel immer mit einer starken Passphrase
• Verwenden Sie ssh-copy-id für schnelle, fehlerfreie Schlüsselbereitstellung, wenn möglich
• Überprüfen Sie, ob die .ssh-Verzeichnisberechtigungen 700 sind und authorized_keys 600 ist
• Bestätigen Sie, dass der Besitz von .ssh und authorized_keys dem Zielbenutzer entspricht
• Testen Sie die Schlüsselanmeldung in einem zweiten Terminal bevor Sie die Passwortauthentifizierung deaktivieren
• Führen Sie sshd -t aus, um die Konfigurationssyntax vor dem Neustart des Daemons zu validieren
• Setzen Sie mindestens PermitRootLogin prohibit-password; bevorzugen Sie no mit einem sudo-Benutzer
• Prüfen Sie /etc/ssh/sshd_config.d/ auf Drop-in-Dateien, die Ihre Einstellungen überschreiben könnten
• Verwenden Sie ~/.ssh/config-Aliase, um mehrere Server übersichtlich zu verwalten
• Prüfen und rotieren Sie Schlüssel regelmäßig; widerrufen Sie sie sofort bei Personal- oder Geräteänderungen
• Führen Sie auf SELinux-Systemen restorecon -Rv ~/.ssh nach manuellen Dateioperationen aus

FAQ

Kann ich mehrere öffentliche SSH-Schlüssel zum selben VPS-Benutzerkonto hinzufügen?

Ja. Jede Zeile in ~/.ssh/authorized_keys ist ein unabhängiger autorisierter Schlüssel. Fügen Sie einen Schlüssel pro Zeile hinzu. Dies ist der Standardansatz, um mehreren Administratoren oder von mehreren Geräten aus Zugang zu gewähren — jede Person oder jedes Gerät besitzt einen einzigartigen privaten Schlüssel, und der Widerruf erfolgt zeilenweise.

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

Sie werden vom SSH ausgesperrt. Zur Wiederherstellung müssen Sie den Out-of-Band-Konsolenzugang Ihres Hosting-Anbieters (KVM/VNC) verwenden, der über die meisten VPS Hosting-Kontrollpanels verfügbar ist. Aktivieren Sie von der Konsole aus PasswordAuthentication yes in /etc/ssh/sshd_config wieder, starten Sie sshd neu und laden Sie einen neuen Schlüssel hoch. Deshalb ist das Testen der Schlüsselanmeldung vor dem Deaktivieren von Passwörtern unverzichtbar.

Wird Ed25519 auf allen Servern unterstützt?

Ed25519 erfordert OpenSSH 6.5 oder höher (veröffentlicht 2014). Jede moderne Linux-Distribution — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — unterstützt es nativ. Nur wirklich veraltete Systeme erfordern einen RSA-Fallback.

Sollte ich dasselbe SSH-Schlüsselpaar für jeden Server verwenden, den ich verwalte?

Es ist operativ bequem, schafft aber einen einzelnen Kompromittierungspunkt. Eine bessere Praxis ist es, ein Schlüsselpaar pro Rolle oder Umgebung zu verwenden (z. B. ein Schlüssel für persönliche Server, einer für Client-Infrastruktur). Dies begrenzt den Schadensradius, falls ein privater Schlüssel jemals offengelegt wird.

Beeinflusst das Hochladen eines SSH-Schlüssels meine SSL Certificates oder die Webserver-Konfiguration?

Nein. SSH-Schlüssel regeln den Terminal-Zugang zum Betriebssystem und sind vollständig getrennt von TLS/SSL-Zertifikaten, die von Webservern (Apache, Nginx) für HTTPS verwendet werden. Sie verwenden unterschiedliche Ports (22 vs. 443), unterschiedliche Schlüsselformate und unterschiedliche Vertrauensketten. Eine Änderung der einen hat keinerlei Auswirkung auf die andere.