SSH-Schlüssel unter Linux: sicher vom Laptop zum Server

Eine SSH-Anmeldung mit einem eigenen Schlüssel macht regelmäßige Serverarbeit übersichtlich. Für meine Website ist worldnode der konkrete Serverbezug: Dort liegt der Checkout unter /srv/www/dennishilk.github.io. Ein Schlüssel und ein kurzer Host-Alias können diesen täglichen Weg vereinfachen.

Hier zeige ich einen allgemeinen Linux/OpenSSH-Ablauf. Die Domain server.example.com und die gezeigte Client-Konfiguration sind anzupassende Beispiele. Der Artikel behauptet keine bestimmte bestehende SSH-Konfiguration meines Servers. Du brauchst ein vorhandenes Benutzerkonto und einen bereits autorisierten Anmeldeweg dorthin.

Zwei Schlüssel mit verschiedenen Aufgaben

ssh-keygen erzeugt ein Schlüsselpaar. Der private Teil bleibt auf deinem Laptop. Der öffentliche Teil, üblicherweise mit .pub am Dateiende, darf auf dem Server für dein Benutzerkonto hinterlegt werden.

Der Server prüft bei der Anmeldung, ob der Client den passenden privaten Schlüssel besitzt. Dafür musst du den privaten Schlüssel nicht auf den Server kopieren. Eine Passphrase schützt zusätzlich die lokale Schlüsseldatei; sie ist ein anderes Geheimnis als das Kennwort des Serverkontos.

Einen eigenen Schlüssel erstellen

Erstelle das lokale SSH-Verzeichnis, falls es fehlt:

mkdir -p ~/.ssh

Prüfe mit dem Dateimanager oder einer Verzeichnisliste, dass der folgende Dateiname noch nicht verwendet wird. Verwende sonst einen anderen Namen; überschreibe keinen vorhandenen Schlüssel.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_worldnode -C "laptop-worldnode"

Wähle eine Passphrase beim interaktiven Dialog. Der Kommentar ist eine lesbare Bezeichnung, keine Serverfreigabe. Er muss keine E-Mail-Adresse enthalten. Nach dem Erstellen liegen der private Schlüssel und die öffentliche .pub-Datei getrennt vor.

Den Fingerabdruck des öffentlichen Schlüssels kannst du prüfen:

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

Dieser Fingerabdruck bezeichnet deinen Benutzerschlüssel. Er ist nicht der Fingerabdruck des SSH-Servers, der im nächsten Schritt geprüft wird.

Den Server vor der ersten Anmeldung erkennen

Bei der ersten Verbindung zeigt SSH häufig einen unbekannten Host-Schlüssel an. Vergleiche dessen Fingerabdruck über einen bereits vertrauenswürdigen Weg, etwa die Serverkonsole oder eine vorhandene administrativ bestätigte Dokumentation.

Ein Hostname und eine passende IP allein bestätigen die Identität nicht. Auch ein später veränderter Host-Schlüssel verdient eine Erklärung: Ein neu installiertes System ist eine mögliche Ursache, aber kein Grund, jede Warnung ungeprüft wegzuklicken oder den Eintrag blind zu löschen.

Die Hostprüfung schützt die Verbindung zum richtigen Ziel. Der Benutzerschlüssel beantwortet anschließend die andere Frage: Darfst du dich mit diesem Konto anmelden? Beide Prüfungen gehören zum Ablauf.

Nur den öffentlichen Schlüssel übertragen

Ersetze server.example.com durch deinen tatsächlichen Server und gegebenenfalls nebu durch dein Konto:

ssh-copy-id -i ~/.ssh/id_ed25519_worldnode.pub nebu@server.example.com

Der Befehl benötigt einen funktionierenden vorhandenen Anmeldeweg, häufig zunächst das Kontokennwort. Er hinterlegt den ausgewählten öffentlichen Schlüssel in der erlaubten Schlüsselliste des Zielkontos. Die private Datei wird dabei nicht übertragen.

Teste anschließend ausdrücklich den neuen Schlüssel:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_worldnode nebu@server.example.com

Eine lokale Passphrase-Abfrage kann dabei normal sein. Eine erneute Abfrage des Serverkennworts kann auf einen anderen Anmeldeweg hinweisen. Prüfe, ob der erwartete Benutzer und Host verbunden sind. Halte einen bestehenden funktionierenden Zugang offen, bis der neue Weg erfolgreich getestet ist.

Einen übersichtlichen Host-Alias anlegen

Sichere eine vorhandene ~/.ssh/config und ergänze mit deinem Editor einen passenden Abschnitt. Falls dort bereits Host worldnode steht, ändere den vorhandenen Abschnitt bewusst statt konkurrierende Einträge hinzuzufügen:

Host worldnode
    HostName server.example.com
    User nebu
    IdentityFile ~/.ssh/id_ed25519_worldnode
    IdentitiesOnly yes

Host ist der lokale Kurzname; HostName das tatsächliche Ziel. IdentityFile wählt den privaten Schlüssel und IdentitiesOnly begrenzt die angebotenen Identitäten. Passe Domain, Benutzer und Dateinamen zusammen an.

Danach genügt:

ssh worldnode

Die aufgelösten Client-Einstellungen kannst du ohne Anmeldung ansehen:

ssh -G worldnode

Die Ausgabe enthält auch persönliche Zielinformationen; teile sie nicht ungeprüft vollständig.

Passphrase und SSH-Agent verstehen

Ein SSH-Agent kann einen entsperrten Schlüssel für deine Sitzung bereithalten, damit du die Passphrase nicht bei jeder Anmeldung erneut eingibst. Wenn deine Desktop-Sitzung bereits einen erreichbaren Agent bereitstellt:

ssh-add ~/.ssh/id_ed25519_worldnode

Ohne Agent-Verbindung scheitert der Befehl. Die Einrichtung hängt von Desktop und Shell ab; kopiere keinen Bash-Agent-Start ungeprüft in fish. Das Tutorial benötigt keinen neu gestarteten Agent, weil der direkte Schlüsselaufruf aus dem vorherigen Abschnitt bereits funktioniert.

Der Agent ersetzt keinen gesicherten privaten Schlüssel. Lass eine entsperrte Sitzung nicht ungeschützt zugänglich und gib den privaten Teil nicht an Dritte weiter.

Typische Fehler und ein sauberer Rückweg

Bei Schlüsseln und .ssh-Verzeichnissen müssen Eigentümer und Rechte zur Benutzerkonfiguration passen. Lokal sind 700 für .ssh und 600 für private Dateien übliche restriktive Werte. Auf dem Server beeinflussen auch dessen Prüfregeln, ob authorized_keys akzeptiert wird.

Wenn du den Übungsschlüssel später entfernst, nimm gezielt dessen öffentlichen Eintrag aus authorized_keys, nachdem ein anderer Zugang funktioniert. Entferne nicht pauschal die ganze Datei. Eine Änderung der Server-Anmeldepolitik gehört nicht zu dieser Übung.

Quellen und der nächste Server-Schritt

Nach der Anmeldung kannst du deinen Website-Checkout bewusst aktualisieren. Der Git-Artikel erklärt dafür, warum lokale Server-Commits manchmal einen Rebase oder Merge erfordern.

• OpenSSH-Handbücher.
• ssh-keygen und ssh_config.
• ssh-copy-id aus Debian.

Referenzen geprüft am 8. Oktober 2026. Alle Serverdomains im Einrichtungsbeispiel sind Platzhalter.