By Ralf-Peter Kleinert
Hallo liebe Leserinnen und Leser. Ich habe wirklich versucht, das SSH-Key erstellen so knapp wie möglich zu machen, doch beim Schreiben hat sich herausgestellt, dass man das nicht enfach Like TikTok machen kann. Die Informationen die der gesamte Artikel mitliefert sind absolut unerlässlich um SSH-Keys korrekt anwenden zu können. Bitte machen Sie hier nicht den Fehler alles schnell und unüberlegt abzuarbeiten. Das ist einfach zu wichtig!
Blitzanleitung: SSH-Schlüssel erstellen, installieren und absichern, Windows
1. SSH-Schlüssel unter Windows erstellen
Windows PowerShell öffnen:
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.ssh"
ssh-keygen -t ed25519 -a 100 -C "Eindeutiger_Name_Maschinenname" -f "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname"
Vergeben Sie eine sichere Passphrase und bewahren Sie diese in einem Passwortmanager auf.
2. Öffentlichen SSH-Schlüssel auf den Server übertragen
Windows PowerShell:
Get-Content "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname.pub" | ssh root@192.168.2.100 "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
Prüfen Sie bei der ersten Verbindung den SSH-Host-Fingerabdruck, bestätigen Sie mit yes und geben Sie das Root-Passwort des Servers ein.
3. SSH-Schlüssel testen
Windows PowerShell:
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Die Anmeldung muss mit Ihrem SSH-Schlüssel funktionieren.
4. SSH-Schlüssel sichern
Sichern Sie jetzt Ihren privaten und öffentlichen SSH-Schlüssel sowie die Passphrase, beispielsweise in einer verschlüsselten KeePassXC-Datenbank.
Erst nach erfolgreicher Sicherung fortfahren!
5. SSH-Passwortanmeldung deaktivieren
Auf dem Linux-Server:
nano /etc/ssh/sshd_config
Folgende Einstellungen setzen:
PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
Datei speichern und anschließend die Konfiguration prüfen:
sshd -t
6. SSH-Dienst neu laden
Debian, Ubuntu, Proxmox VE und PBS:
systemctl restart ssh
Fedora, AlmaLinux und Rocky Linux:
systemctl reload sshd
Wirksame Einstellungen kontrollieren:
sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'
Erwartete Werte:
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
7. Passwortanmeldung überprüfen
In einem zweiten PowerShell-Fenster:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive root@192.168.2.100
Die Passwortanmeldung muss abgewiesen werden.
8. SSH-Schlüsselanmeldung abschließend testen
Windows PowerShell:
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Funktioniert die Anmeldung, ist die Einrichtung abgeschlossen.
Wichtig: Ersetzen Sie die Beispiel-IP-Adresse und die Platzhalter im Schlüsselnamen durch Ihre eigenen Angaben. Lassen Sie Ihre bestehende SSH-Verbindung geöffnet, bis sämtliche Tests erfolgreich abgeschlossen sind.
Proxmox-Hinweis: Bei Proxmox-Clustern müssen interne SSH-Verbindungen weiterhin funktionieren. Deaktivieren Sie nicht pauschal den Root-SSH-Zugang.
Schnellanleitung zur Installation von SSH-Schlüsseln, Windows
Info: Damit sie einen SSH-Schlüssel für den Benutzer root auf dem Server einrichten können, benötigen sie zunächst einen funktionierenden Zugang zum Server. Für die Installation über eine SSH-Verbindung muss die Anmeldung als root mit Passwort vorübergehend erlaubt sein.
Da ihnen Proxmox VE und Proxmox Backup Server über ihre Weboberflächen einen direkten Zugriff auf die Shell ermöglichen, können sie den öffentlichen SSH-Schlüssel auch auf diesem Weg installieren. Eine vorherige SSH-Anmeldung mit Passwort ist dann nicht erforderlich. Allerdings bieten nicht alle Linux-Systeme eine solche Möglichkeit.
Tipp: Auch wenn hier oben die Schnellanleitung sofort angewandt werden kann, empfehle ich unter der Überschrift „Genaue Erklärung des Befehles zur Erzeugung des SSH-Schlüssels“ nachzulesen, wie diese Technologie überhaupt funktioniert. So verstehen Sie auch besser, wenn es zu Problemen kommt.
Befehl zur Erzeugung eines SSH-Schlüssels unter Windows Powershell
Erstellen des .ssh-Ordners im User-Ordner, falls er noch nicht vorhanden ist:
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.ssh"
Tragen Sie in diesen Befehl den eindeutigen Namen der Ziel-Maschine ein, damit sie diese bei mehreren Schlüsseln auch auseinanderhalten können:
ssh-keygen -t ed25519 -a 100 -C "Eindeutiger_Name_Maschinenname" -f "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname"
Nachdem sie den Befehl ausgeführt haben, werden sie in der PowerShell aufgefordert, eine Passphrase zu vergeben. Diese schützt ihren privaten SSH-Schlüssel vor unbefugtem Zugriff.
Bitte verwenden Sie eine zufällig generierte, sichere und einmalige Passphrase mit mindestens 64 Zeichen und speichern Sie diese sicher in einem Passwortmanager wie KeePassXC! KeePassXC kann solche Passwörter generieren.
Den neuen generierten Schlüssel auf den Server übertragen
Nachdem sie ihren SSH-Schlüssel unter Windows erstellt haben, müssen sie den öffentlichen Schlüssel auf ihren Linux-Server übertragen. Der private Schlüssel verbleibt auf ihrem Windows-PC und darf niemals auf den Server kopiert werden.
Für die Übertragung öffnen sie die Windows PowerShell und führen folgenden Befehl aus:
Die IP-Adresse 192.168.2.100 ersetzen sie durch die tatsächliche IP-Adresse ihres Servers und id_ed25519_Eindeutiger_Name_Maschinenname.pub ersetzen sie durch den tatsächlichen Namen ihrer Schlüsseldatei.
Get-Content "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname.pub" | ssh root@192.168.2.100 "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
Wichtig: Bevor sie die Abfrage bestätigen, sollten sie den angezeigten SHA256-Fingerabdruck mit dem tatsächlichen Fingerabdruck des Servers vergleichen. Diesen können sie beispielsweise direkt über die Serverkonsole überprüfen.
Stimmt der Fingerabdruck überein, bestätigen sie die Abfrage mit: yes
Nach der Eingabe von yes werden sie aufgefordert, das Root-Passwort ihres Linux-Servers einzugeben. Ist das Passwort korrekt, wird der öffentliche SSH-Schlüssel auf den Server übertragen und dort hinterlegt.
Die Übertragung erfolgt normalerweise ohne weitere Bestätigung oder Erfolgsmeldung. Anschließend kehrt die PowerShell zur gewohnten Eingabeaufforderung zurück.
Ob die Übertragung erfolgreich war und die Anmeldung mit ihrem SSH-Schlüssel funktioniert, überprüfen sie im nächsten Schritt.
Übertragenen Schlüssel testen
Die IP-Adresse 192.168.2.100 ersetzen sie durch die tatsächliche IP-Adresse ihres Servers und id_ed25519_Eindeutiger_Name_Maschinenname ersetzen sie durch den tatsächlichen Namen ihrer Schlüsseldatei.
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Mit diesem Befehl erzwingen sie die Anmeldung über ihren zuvor erstellten SSH-Schlüssel. Eine Anmeldung mit dem Root-Passwort ist bei diesem Test ausgeschlossen.
Wenn alles funktioniert, werden sie nach der Passphrase ihres privaten SSH-Schlüssels gefragt. Nach korrekter Eingabe erfolgt die Anmeldung am Linux-Server.
Sollte der Schlüssel bereits über einen SSH-Agent entsperrt sein, kann die Anmeldung auch ohne erneute Passphrase-Abfrage erfolgen.
Wichtig: Wenn sie sich erfolgreich anmelden können, ohne das Root-Passwort des Servers einzugeben, ist die Einrichtung ihres SSH-Schlüssels abgeschlossen.
Falls die Berechtigungen des SSH-Ordners nicht korrekt sind
Sollte die Anmeldung mit Ihrem SSH-Schlüssel trotz korrekter Einrichtung nicht funktionieren, könnte dies an falsch gesetzten Zugriffsrechten auf dem Linux-Server liegen.
Der Befehl zur Übertragung des öffentlichen SSH-Schlüssels setzt die Berechtigungen nur für neu erstellte Dateien und Verzeichnisse. Bereits vorhandene Verzeichnisse und Dateien behalten ihre bisherigen Berechtigungen.
Mit den folgenden beiden Befehlen können Sie die Berechtigungen korrigieren:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Erklärung:
- chmod 700: Nur der Besitzer darf auf das SSH-Verzeichnis zugreifen, dessen Inhalt anzeigen und darin Änderungen vornehmen.
- chmod 600: Nur der Besitzer darf die Datei mit den autorisierten SSH-Schlüsseln lesen und verändern.
Führen Sie diese Befehle auf dem Linux-Server mit dem Benutzer aus, für den Sie den SSH-Schlüssel eingerichtet haben. In dieser Anleitung ist das der Benutzer Root.
Anschließend können Sie die SSH-Anmeldung erneut testen. Ein Neustart des SSH-Dienstes ist dafür nicht erforderlich.
Jetzt unbedingt! SSH-Schlüssel sicher aufbewahren
Bevor sie weitermachen, sollten sie ihre neu erstellten SSH-Schlüssel sichern.
Entweder verfügen Sie bereits über eine zuverlässige Backupstrategie oder Sie nutzen die Gelegenheit, sich Gedanken über eine geeignete Sicherung zu machen. Schließlich möchten sie vermeiden, dass ihre SSH-Schlüssel durch einen PC-Fehler, einen Hardwaredefekt oder einen anderen Datenverlust verloren gehen.
Ich persönlich verwende KeePassXC, um meine SSH-Schlüssel sicher aufzubewahren. Dazu speichere ich die neu erstellten Schlüssel als Anhänge in meiner KeePassXC-Datenbank, versehe sie mit eindeutigen Namen und ergänze entsprechende Beschreibungen. So kann ich auch Jahre später noch nachvollziehen, welcher Schlüssel zu welchem Server gehört.
Anschließend warte ich, bis meine aktualisierte KeePassXC-Datenbank über pCloud synchronisiert wurde und zusätzlich durch Iperius Backup gesichert ist.
Erst wenn diese Sicherungen abgeschlossen sind, mache ich weiter.
Der Hintergrund ist einfach: Wenn sie im nächsten Schritt die SSH-Anmeldung per Passwort deaktivieren und später ihren privaten SSH-Schlüssel verlieren, ist eine Anmeldung über SSH möglicherweise nicht mehr möglich.
Je nach Server stehen ihen zwar alternative Zugangsmöglichkeiten zur Verfügung, beispielsweise über eine lokale Konsole oder die Weboberfläche von Proxmox. Dennoch ist es wesentlich angenehmer, wenn wir auf solche Wiederherstellungsmaßnahmen gar nicht erst angewiesen sind.
Meine Empfehlung: Bewahren Sie den privaten und öffentlichen Schlüssel sowie die zugehörige Passphrase sicher auf. Achten Sie darauf, dass Ihre Sicherungen zuverlässig funktionieren und sich bei Bedarf auch wiederherstellen lassen.
Erst nach der Sicherung! SSH-Passwortanmeldung deaktivieren
Nachdem sie erfolgreich überprüft haben, dass die Anmeldung mit ihrem SSH-Schlüssel funktioniert, können sie die Anmeldung über ein normales Benutzerpasswort deaktivieren. Dadurch verhindern sie, dass sich jemand allein durch die Kenntnis oder das Erraten eines Passworts per SSH auf ihrem Server anmelden kann.
Wichtig: Sie lassen ihre bestehende SSH-Verbindung geöffnet, bis sie die neue Konfiguration erfolgreich getestet haben. So können sie mögliche Fehler korrigieren, ohne sich selbst auszusperren.
Zunächst öffnen sie auf ihrem Linux-Server die SSH-Konfigurationsdatei:
nano /etc/ssh/sshd_config
Sie suchen nach den folgenden Einstellungen und setzen diese Werte:
Das speichern der Dateien via Nano: STRG + O
PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
Konfiguration überprüfen
Bevor sie die Änderungen aktivieren, prüfen sie die SSH-Konfiguration auf Fehler:
sshd -t
Erscheint keine Fehlermeldung, ist die Konfiguration syntaktisch korrekt.
Bei Debian, Ubuntu, Proxmox VE und Proxmox Backup Server laden sie den SSH-Dienst anschließend neu:
systemctl restart ssh
Bei Fedora, AlmaLinux und Rocky Linux lautet der Befehl normalerweise:
systemctl reload sshd
Wirksame SSH-Konfiguration überprüfen
Nachdem Sie den SSH-Dienst neu geladen haben, sollten Sie überprüfen, ob die gewünschten Sicherheitseinstellungen tatsächlich übernommen wurden.
Führen Sie dazu auf Ihrem Linux-Server folgenden Befehl aus:
sshd -T | grep -Ei 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'
Die Ausgabe sollte folgende Werte enthalten:
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
Erklärung:
- PermitRootLogin prohibit-password: root darf sich anmelden, aber nicht mit Passwort.
- pubkeyauthentication yes: Die Anmeldung mit SSH-Schlüsseln ist erlaubt.
- passwordauthentication no: Die Anmeldung mit einem normalen Benutzerpasswort ist deaktiviert.
- kbdinteractiveauthentication no: Die interaktive Authentifizierung, über die ebenfalls Passwörter abgefragt werden könnten, ist deaktiviert.
Wichtig: Sollten andere Werte angezeigt werden, überprüfen Sie die SSH-Konfiguration. Einige Linux-Distributionen verwenden zusätzliche Konfigurationsdateien, deren Einstellungen Vorrang haben können.
Bei benutzer- oder IP-abhängigen SSH-Regeln muss die wirksame Konfiguration zusätzlich für den jeweiligen Zugang geprüft werden.
Passwortanmeldung überprüfen
Sie öffnen ein zweites PowerShell-Fenster und versuchen, sich ausdrücklich nur mit einem Passwort anzumelden:
Die IP-Adresse 192.168.2.100 ersetzen sie durch die tatsächliche IP-Adresse ihres Servers.
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive root@192.168.2.100
Wenn die Passwortanmeldung erfolgreich deaktiviert wurde, sollte die Verbindung mit einer Meldung wie dieser abgewiesen werden:
Permission denied (publickey)
Anschließend testen sie erneut die Anmeldung mit unserem SSH-Schlüssel:
Die IP-Adresse 192.168.2.100 ersetzen sie durch die tatsächliche IP-Adresse ihres Servers und id_ed25519_Eindeutiger_Name_Maschinenname ersetzen sie durch den tatsächlichen Namen ihrer Schlüsseldatei.
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Wenn alles korrekt eingerichtet wurde, werden Sie gegebenenfalls nach der Passphrase Ihres privaten SSH-Schlüssels gefragt. Nach erfolgreicher Eingabe werden Sie direkt auf dem Linux-Server angemeldet.
Damit ist die Einrichtung abgeschlossen! Ihr Linux-Server akzeptiert nun die Anmeldung über einen gültigen SSH-Schlüssel. Die Anmeldung über das normale Benutzerpasswort ist deaktiviert, sofern die zuvor vorgenommenen Einstellungen wirksam sind.
Abschließender Sicherheitshinweis
Bewahren Sie Ihren privaten SSH-Schlüssel und die zugehörige Passphrase weiterhin sicher auf. Ohne den passenden privaten Schlüssel ist eine Anmeldung über SSH nicht mehr möglich, sofern keine andere Authentifizierungsmethode eingerichtet wurde.
Wichtig: Die Deaktivierung der Passwortanmeldung betrifft ausschließlich den SSH-Dienst. Die Anmeldung über eine lokale Konsole oder beispielsweise die Weboberfläche von Proxmox VE beziehungsweise Proxmox Backup Server bleibt davon grundsätzlich unberührt.
Sie können Ihren Server jetzt wie gewohnt administrieren, allerdings mit einer deutlich besser abgesicherten SSH-Anmeldung.
Entfernen eines SSH-Schlüssels vom Server
Es kann vorkommen, dass Sie einen SSH-Schlüssel nicht mehr benötigen. Beispielsweise, weil Sie einen Computer ausgetauscht, einen neuen SSH-Schlüssel erstellt haben oder einem Administrator den Zugriff auf einen Server entziehen möchten.
In diesem Fall können Sie den betreffenden öffentlichen SSH-Schlüssel ganz einfach vom Linux-Server entfernen.
Wichtig: Wenn Sie den einzigen funktionierenden SSH-Schlüssel entfernen und die Passwortanmeldung bereits deaktiviert haben, können Sie sich anschließend möglicherweise nicht mehr über SSH anmelden. Stellen Sie deshalb vorher sicher, dass Ihnen ein anderer funktionierender Zugang zur Verfügung steht.
1. Auf dem Linux-Server anmelden
Melden Sie sich zunächst wie gewohnt über SSH auf Ihrem Linux-Server an.
2. Datei mit den autorisierten SSH-Schlüsseln öffnen
Öffnen Sie auf dem Linux-Server die Datei mit den hinterlegten öffentlichen SSH-Schlüsseln:
nano ~/.ssh/authorized_keys
In dieser Datei befinden sich alle öffentlichen SSH-Schlüssel, die für den aktuell angemeldeten Benutzer zur Anmeldung zugelassen sind.
Ein Eintrag könnte beispielsweise folgendermaßen aussehen:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... Eindeutiger_Name_Maschinenname
Am Ende jedes Schlüssels befindet sich normalerweise der Kommentar, den Sie bei der Erstellung vergeben haben.
Genau deshalb haben Sie bei der Schlüsselerstellung einen eindeutigen Namen verwendet! So können Sie die einzelnen Schlüssel auch später problemlos zuordnen.
3. SSH-Schlüssel entfernen
Suchen Sie den öffentlichen SSH-Schlüssel, den Sie entfernen möchten, und löschen Sie die entsprechende Zeile vollständig.
Achten Sie darauf, dass Sie keine anderen Schlüssel versehentlich verändern oder löschen.
Speichern Sie die Datei anschließend mit Strg + O, bestätigen Sie mit Enter und verlassen Sie Nano mit Strg + X.
4. Entfernung überprüfen
Der entfernte SSH-Schlüssel kann jetzt nicht mehr für neue Anmeldungen an diesem Benutzerkonto verwendet werden.
Ein Neustart des SSH-Dienstes ist dafür nicht erforderlich. Änderungen an der Datei mit den autorisierten SSH-Schlüsseln werden automatisch bei neuen Anmeldeversuchen berücksichtigt.
Sie können die Entfernung überprüfen, indem Sie von Ihrem Windows-PC aus erneut versuchen, sich mit dem entfernten Schlüssel anzumelden:
Die IP-Adresse 192.168.2.100 ersetzen sie durch die tatsächliche IP-Adresse ihres Servers und id_ed25519_Eindeutiger_Name_Maschinenname ersetzen sie durch den tatsächlichen Namen ihrer Schlüsseldatei.
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Wenn der entfernte Schlüssel nicht mehr akzeptiert wird und keine andere zulässige Authentifizierungsmöglichkeit für diesen Versuch besteht, sollte die Anmeldung mit einer Fehlermeldung wie dieser abgewiesen werden:
Permission denied (publickey)
Wichtig: Bereits bestehende SSH-Verbindungen werden durch das Entfernen eines Schlüssels nicht automatisch beendet. Die Änderung betrifft zunächst nur neue Anmeldeversuche.
5. Was passiert mit dem privaten SSH-Schlüssel?
Der private SSH-Schlüssel auf Ihrem Windows-PC bleibt unverändert bestehen. Durch das Entfernen des öffentlichen Schlüssels vom Server verliert er lediglich seine Zugangsberechtigung für das betreffende Benutzerkonto.
Wenn Sie den Schlüssel auch auf anderen Servern installiert haben, funktioniert er dort weiterhin.
Möchten Sie einem Schlüssel sämtliche Zugriffsberechtigungen entziehen, müssen Sie den entsprechenden öffentlichen Schlüssel auf allen betroffenen Servern entfernen.
Tipp: Wenn Sie SSH-Schlüssel für mehrere Kunden oder Server verwalten, dokumentieren Sie auch das Entfernen beziehungsweise Ersetzen eines Schlüssels. So behalten Sie jederzeit den Überblick darüber, welche Schlüssel auf welchen Systemen verwendet werden.
Wenn Sie PuTTY oder KiTTY verwenden
Sofern Sie sich mit Ihren Servern über PuTTY oder KiTTY verbinden, benötigen Sie bei Verwendung der PuTTY-basierten SSH-Clients sogenannte PPK-Schlüssel. Das sind private SSH-Schlüssel in einem speziellen Format, mit dem diese Programme arbeiten.
Keine Sorge, Sie müssen dafür keine neuen SSH-Schlüssel erstellen oder Ihre bereits eingerichteten Server verändern. Ihre vorhandenen Schlüssel können Sie ganz einfach in das benötigte Format umwandeln.
Dazu benötigen Sie das kostenlose Programm PuTTYgen, das Sie auf der offiziellen PuTTY-Webseite auch einzeln herunterladen können. Eine vollständige Installation von PuTTY ist dafür nicht erforderlich.
Starten Sie PuTTYgen und wählen Sie im Menü Conversions → Import key. Öffnen Sie anschließend Ihren bereits erstellten privaten SSH-Schlüssel aus dem Verzeichnis C:\Users\IhrBenutzername\.ssh. Achten Sie darauf, dass Sie die Datei ohne die Endung .pub auswählen. Die .pub-Datei enthält lediglich den öffentlichen Schlüssel und ist für diese Umwandlung nicht geeignet.
Falls Sie Ihren privaten Schlüssel mit einer Passphrase geschützt haben, werden Sie nun aufgefordert, diese einzugeben. Anschließend klicken Sie auf Save private key und speichern den Schlüssel mit der Dateiendung .ppk ab.
Fertig! Diesen PPK-Schlüssel können Sie jetzt in PuTTY, KiTTY oder einer entsprechend konfigurierten mRemoteNG-Verbindung verwenden.
Wichtig: Ihr ursprünglicher privater SSH-Schlüssel bleibt dabei unverändert. Sie haben lediglich eine zusätzliche Datei für die Verwendung mit PuTTY-kompatiblen SSH-Clients erstellt. Bewahren Sie auch diese PPK-Datei sicher auf, denn sie enthält Ihren privaten SSH-Schlüssel.
SSH-Schlüssel direkt unter Linux erstellen
Bisher haben wir unsere SSH-Schlüssel unter Windows mit der PowerShell erstellt. Natürlich funktioniert das Ganze auch direkt unter Linux. Wer beispielsweise mit einem Linux-Desktop, einem Notebook mit Debian oder Ubuntu arbeitet, kann seine SSH-Schlüssel direkt im Terminal erstellen.
Das Verfahren unterscheidet sich kaum von unserer Windows-Anleitung. Wir verwenden auch hier den sicheren Ed25519-Algorithmus, schützen unseren privaten Schlüssel mit einer Passphrase und vergeben einen eindeutigen Namen, damit wir unsere Schlüssel später problemlos auseinanderhalten können.
SSH-Verzeichnis unter Linux erstellen
Zunächst öffnen wir ein Terminal auf unserem Linux-Rechner. Wir stellen sicher, dass das SSH-Verzeichnis in unserem Benutzerordner vorhanden ist und die richtigen Berechtigungen besitzt.
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Der erste Befehl erstellt das Verzeichnis, sofern es noch nicht vorhanden ist. Der zweite Befehl sorgt dafür, dass ausschließlich unser Benutzer auf dieses Verzeichnis zugreifen kann.
Wichtig: Wir führen diese Befehle auf unserem lokalen Linux-Rechner aus, von dem aus wir später die Verbindung zum Server herstellen möchten. Nicht auf dem Zielserver!
SSH-Schlüssel unter Linux erzeugen
Jetzt erstellen wir unseren SSH-Schlüssel. Genau wie unter Windows verwenden wir Ed25519 mit 100 KDF-Runden und einem eindeutigen Dateinamen.
ssh-keygen -t ed25519 -a 100 -C "Eindeutiger_Name_Maschinenname" -f "$HOME/.ssh/id_ed25519_Eindeutiger_Name_Maschinenname"
Ersetzen Sie Eindeutiger_Name_Maschinenname durch eine Bezeichnung, mit der Sie Ihren Schlüssel später eindeutig zuordnen können.
Nach der Ausführung werden Sie aufgefordert, eine Passphrase einzugeben. Ich empfehle auch hier eine zufällig generierte Passphrase mit mindestens 64 Zeichen, die Sie beispielsweise mit KeePassXC erstellen und sicher aufbewahren können.
Anschließend befinden sich zwei Dateien in unserem SSH-Verzeichnis. Die Datei ohne Endung ist unser privater Schlüssel. Die Datei mit der Endung .pub enthält den öffentlichen Schlüssel, den wir gleich auf unseren Linux-Server übertragen.
Wichtig: Der private SSH-Schlüssel verbleibt auf unserem lokalen Rechner und darf niemals zur Einrichtung der Anmeldung auf den Zielserver kopiert werden!
Öffentlichen SSH-Schlüssel auf den Server übertragen
Unter Linux haben wir es an dieser Stelle sogar etwas einfacher als unter Windows. Mit dem Programm ssh-copy-id können wir unseren öffentlichen Schlüssel direkt auf dem Zielserver hinterlegen.
ssh-copy-id -i "$HOME/.ssh/id_ed25519_Eindeutiger_Name_Maschinenname.pub" root@192.168.2.100
Ersetzen Sie die Beispiel-IP-Adresse durch die tatsächliche IP-Adresse Ihres Servers und passen Sie den Namen der Schlüsseldatei entsprechend an.
Bei der ersten Verbindung sollten Sie unbedingt den angezeigten SSH-Fingerabdruck mit dem tatsächlichen Fingerabdruck Ihres Servers vergleichen. Diesen können Sie beispielsweise über die lokale Serverkonsole überprüfen.
Stimmt der Fingerabdruck überein, bestätigen Sie die Verbindung und geben anschließend das Root-Passwort Ihres Servers ein.
Das Programm ssh-copy-id kümmert sich nun darum, den öffentlichen Schlüssel in der Datei authorized_keys auf dem Zielserver zu hinterlegen. Bereits vorhandene Schlüssel bleiben dabei erhalten. Außerdem verhindert ssh-copy-id normalerweise, dass derselbe Schlüssel mehrfach eingetragen wird.
Hinweis: Sollte ssh-copy-id auf Ihrem Linux-Rechner nicht installiert sein, können Sie das Programm bei Debian und Ubuntu über das Paket openssh-client nachinstallieren.
SSH-Schlüsselanmeldung überprüfen
Jetzt müssen wir unbedingt testen, ob die Anmeldung mit unserem neuen SSH-Schlüssel funktioniert.
Dazu führen wir auf unserem lokalen Linux-Rechner folgenden Befehl aus:
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -o IdentitiesOnly=yes -i "$HOME/.ssh/id_ed25519_Eindeutiger_Name_Maschinenname" root@192.168.2.100
Mit diesem Befehl erzwingen wir die Anmeldung über unseren SSH-Schlüssel. Die normale Passwortanmeldung ist für diesen Test ausgeschlossen.
Wenn alles korrekt eingerichtet wurde, werden Sie gegebenenfalls nach der Passphrase Ihres privaten SSH-Schlüssels gefragt. Nach erfolgreicher Eingabe sollten Sie direkt auf Ihrem Linux-Server angemeldet sein.
Falls Sie bereits einen SSH-Agent verwenden und Ihr Schlüssel dort entsperrt ist, kann die Anmeldung auch ohne erneute Passphrase-Abfrage erfolgen.
SSH-Schlüssel sichern und Server absichern
Damit haben wir unseren SSH-Schlüssel unter Linux erfolgreich erstellt und auf dem Zielserver eingerichtet.
Bevor Sie jetzt weitermachen, sichern Sie unbedingt Ihren privaten und öffentlichen SSH-Schlüssel sowie die zugehörige Passphrase. Ich persönlich verwende dafür KeePassXC und sichere die Datenbank zusätzlich über meine bestehende Backupstrategie.
Erst wenn die Sicherung abgeschlossen ist und die Anmeldung mit dem SSH-Schlüssel zuverlässig funktioniert, sollten Sie die SSH-Passwortanmeldung auf dem Zielserver deaktivieren.
Die dafür notwendigen Einstellungen, die Überprüfung der SSH-Konfiguration und die abschließenden Sicherheitstests habe ich weiter oben in diesem Artikel bereits ausführlich beschrieben. Diese Schritte gelten unabhängig davon, ob Sie Ihren SSH-Schlüssel unter Windows oder Linux erstellt haben.
Wichtig: Lassen Sie auch hier Ihre bestehende SSH-Verbindung geöffnet, bis Sie die neue Konfiguration erfolgreich in einem zweiten Terminal getestet haben. Gerade bei entfernten Linux-Servern, Proxmox VE und Proxmox Backup Server sollten Sie sich für diese Schritte ausreichend Zeit nehmen.
Genaue Erklärung des Befehles zur Erzeugung des SSH-Schlüssels
Mit dem folgenden Befehl erstellen wir unter Windows einen modernen und sicheren SSH-Schlüssel. Dazu öffnen wir die Windows PowerShell. Eine zusätzliche Softwareinstallation ist normalerweise nicht erforderlich, da OpenSSH unter aktuellen Windows-Versionen bereits vorhanden ist.
Für die Schlüsselerstellung verwenden wir mit Ed25519 einen der modernsten und sichersten SSH-Schlüsselalgorithmen, die uns derzeit zur Verfügung stehen. Er bietet ein sehr hohes Sicherheitsniveau, arbeitet effizient und wird von praktisch allen aktuellen Linux-Distributionen sowie Proxmox VE und Proxmox Backup Server unterstützt.
ssh-keygen -t ed25519 -a 100 -C "Eindeutiger_Name_Maschinenname" -f "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname"
Erklärung der einzelnen Bestandteile
| Bestandteil | Erklärung |
|---|---|
| ssh-keygen | Das Programm zur Erstellung und Verwaltung von SSH-Schlüsseln. |
| -t | Steht für Type und bestimmt den verwendeten Schlüsselalgorithmus. |
| ed25519 | Ein moderner, sehr sicherer und schneller Algorithmus, der von praktisch allen aktuellen Linux-Systemen unterstützt wird. |
| -a | Bestimmt die Anzahl der Runden der Schlüsselableitungsfunktion (KDF), mit der die private Schlüsseldatei bei Verwendung einer Passphrase geschützt wird. |
| 100 | Legt 100 KDF-Runden fest. Das erschwert das Ausprobieren möglicher Passphrasen, falls der private Schlüssel gestohlen wird. |
| -C | Steht für Comment. Damit erhält der öffentliche Schlüssel eine frei wählbare Beschreibung. |
| „Eindeutiger_Name_Maschinenname“ | Dient zur eindeutigen Zuordnung des Schlüssels, beispielsweise zu einem Kunden und einem bestimmten Server. |
| -f | Steht für Filename und legt den Speicherort sowie den Dateinamen des Schlüssels fest. |
| $env:USERPROFILE | Eine Windows-PowerShell-Umgebungsvariable, die automatisch auf das Benutzerverzeichnis des aktuell angemeldeten Windows-Benutzers verweist. |
| \.ssh\ | Das Verzeichnis, in dem SSH-Schlüssel üblicherweise gespeichert werden. |
| id_ed25519_Eindeutiger_Name_Maschinenname | Der frei gewählte Dateiname des privaten SSH-Schlüssels. |
Welche Dateien werden erstellt?
Nach der Ausführung erzeugt Windows zwei zusammengehörige Schlüsseldateien im Verzeichnis .ssh des aktuellen Benutzers.
C:\Users\BENUTZER\.ssh\
│
├── id_ed25519_Eindeutiger_Name_Maschinenname
│
└── id_ed25519_Eindeutiger_Name_Maschinenname.pub
Privater Schlüssel (ohne .pub)
Dieser Schlüssel bleibt ausschließlich auf unserem Windows-Computer. Er dient später dazu, unsere Identität gegenüber dem Linux-Server nachzuweisen. Der private Schlüssel darf niemals weitergegeben oder auf den Server kopiert werden.
Öffentlicher Schlüssel (mit .pub)
Diesen Schlüssel übertragen wir auf den Linux-Server, Proxmox-Host oder die virtuelle Maschine. Er wird dort in der Datei authorized_keys des entsprechenden Linux-Benutzers hinterlegt.
Warum verwenden wir Ed25519?
Ed25519 ist für die SSH-Authentifizierung eine ausgezeichnete Wahl. Der Algorithmus bietet ein sehr hohes Sicherheitsniveau bei vergleichsweise kleinen Schlüsseln und benötigt keine manuelle Festlegung der Schlüssellänge.
Er wird unter anderem von Debian, Ubuntu, Fedora, AlmaLinux, Rocky Linux, Proxmox VE und Proxmox Backup Server unterstützt.
Warum verwenden wir -a 100?
Wenn wir eine Passphrase für unseren privaten SSH-Schlüssel vergeben, wird die Schlüsseldatei verschlüsselt gespeichert.
Die 100 KDF-Runden erhöhen den Rechenaufwand beim Ableiten des Verschlüsselungsschlüssels aus der Passphrase. Dadurch werden automatisierte Versuche, die Passphrase zu erraten, erschwert.
Der Parameter verändert weder die Stärke des Ed25519-Algorithmus noch die Sicherheit der eigentlichen SSH-Verbindung.
Wichtig: Ohne Passphrase entfällt dieser zusätzliche Schutz. Deshalb sollten wir bei der Schlüsselerstellung immer eine ausreichend starke Passphrase vergeben.
Warum verwenden wir eindeutige Namen?
Gerade bei der Administration mehrerer Kundenserver ist eine nachvollziehbare Benennung sinnvoll.
Beispielsweise:
MuellerGmbH_Webserver01
MuellerGmbH_Datenbank01
SchmidtIT_Proxmox01
SchmidtIT_Backupserver01
Dadurch erkennen wir sowohl anhand der Schlüsseldateien auf unserem Windows-PC als auch anhand der Kommentare in den öffentlichen Schlüsseln, welchem Kunden und welcher Maschine ein Schlüssel zugeordnet ist.
Hinweis: Das Verzeichnis .ssh muss vor der Ausführung vorhanden sein. Falls es noch nicht existiert, können wir es in PowerShell mit folgendem Befehl erstellen:
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.ssh"
Damit haben wir die Grundlage geschaffen, um im nächsten Schritt den öffentlichen SSH-Schlüssel auf unseren Linux- oder Proxmox-Server zu übertragen.
.ssh Ordner nicht zu sehen?
Info: Der Ordner .ssh befindet sich im Benutzerverzeichnis von Windows. Der Punkt vor dem Ordnernamen ist eine übliche Namenskonvention unter Linux und Unix für versteckte Dateien und Verzeichnisse. Unter Windows bedeutet der Punkt allein allerdings nicht, dass der Ordner automatisch versteckt ist. Sollte der Ordner im Windows-Explorer nicht sichtbar sein, können wir über Ansicht → Anzeigen → Ausgeblendete Elemente die Anzeige versteckter Dateien und Ordner aktivieren.
Erklärung des Befehles Schlüssel übertragen
Mit dem folgenden PowerShell-Befehl übertragen wir unseren zuvor erstellten öffentlichen SSH-Schlüssel auf den Linux-Server und hinterlegen ihn dort für den Benutzer Root.
Get-Content "$env:USERPROFILE\.ssh\id_ed25519_Eindeutiger_Name_Maschinenname.pub" | ssh root@192.168.2.100 "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
Erklärung der einzelnen Bestandteile
| Bestandteil | Erklärung |
|---|---|
| Get-Content | Ein PowerShell-Befehl, der den Inhalt einer Datei ausliest. |
| $env:USERPROFILE | Verweist auf das Benutzerverzeichnis des aktuell angemeldeten Windows-Benutzers. |
| .ssh | Das Verzeichnis, in dem unsere SSH-Schlüssel gespeichert sind. |
| id_ed25519_Eindeutiger_Name_Maschinenname.pub | Unser zuvor erstellter öffentlicher SSH-Schlüssel. Die Endung .pub kennzeichnet den öffentlichen Schlüssel. |
| | | Das sogenannte Pipe-Zeichen. Es leitet den ausgelesenen Dateiinhalt an den nachfolgenden SSH-Befehl weiter. |
| ssh | Stellt eine verschlüsselte Verbindung zum Linux-Server her. |
| root@192.168.2.100 | Gibt den Benutzernamen Root und die IP-Adresse des Zielservers an. |
| umask 077 | Legt fest, dass neu erstellte Dateien und Verzeichnisse standardmäßig nur für den jeweiligen Benutzer zugänglich sind. |
| mkdir -p ~/.ssh | Erstellt das SSH-Verzeichnis auf dem Linux-Server, falls es noch nicht existiert. |
| cat | Liest die übertragene Schlüsselzeile aus der Standardeingabe. |
| >> | Hängt den öffentlichen Schlüssel an eine vorhandene Datei an, ohne deren bisherigen Inhalt zu überschreiben. |
| ~/.ssh/authorized_keys | Die Datei auf dem Linux-Server, in der die zur Anmeldung berechtigten öffentlichen SSH-Schlüssel gespeichert werden. |
Was passiert bei der Ausführung?
Zunächst liest Windows unseren öffentlichen SSH-Schlüssel aus der entsprechenden Datei aus. Anschließend wird eine SSH-Verbindung zum Linux-Server aufgebaut.
Da wir unseren Schlüssel dort noch nicht installiert haben, müssen wir uns zunächst mit dem Passwort des Root-Benutzers authentifizieren, sofern keine andere Anmeldemethode eingerichtet ist.
Nach erfolgreicher Anmeldung wird der öffentliche Schlüssel automatisch in der Datei mit den autorisierten Schlüsseln hinterlegt.
Wichtig: Bereits vorhandene SSH-Schlüssel werden dabei nicht gelöscht oder überschrieben. Unser neuer Schlüssel wird lediglich ergänzt.
Der private SSH-Schlüssel bleibt während des gesamten Vorgangs auf unserem Windows-PC. Es wird ausschließlich der öffentliche Schlüssel übertragen.
Hinweis: Der Befehl setzt voraus, dass der angemeldete Benutzer Schreibrechte auf sein SSH-Verzeichnis besitzt. Bei bereits vorhandenen Verzeichnissen und Dateien müssen außerdem die Zugriffsrechte korrekt gesetzt sein. Bei root ist das aber der Fall.
Ralf-Peter Kleinert / ComputerRalle
Ich verwende moderne KI-Systeme als unterstützendes Werkzeug, um meine Texte zu strukturieren, sprachlich zu überarbeiten und in eine verständliche Form zu bringen. Dabei nutze ich Künstliche Intelligenz unter anderem zur Korrektur von Rechtschreibung und Grammatik, zur besseren Gliederung von Inhalten sowie zur Optimierung von Formulierungen. Dennoch schreibe ich meine Inhalte zunächst komplett alleine. Bilder und Thumbnails bearbeite ich wieder überwiegend selbst in Photoshop oder PhotoCraft. KI-Bilder sehen alle gleich aus – das passt mir nicht. KI zum korrigieren zu verwenden ist für mich eine enorme Zeitersparnis, sodass ich mich stärker auf die eigentlichen Inhalte konzentrieren kann.