SSH-Key-Authentifizierung ist eine der wichtigsten Grundmaßnahmen für jeden Linux-Server. Statt dich mit einem Passwort anzumelden, nutzt du ein Schlüsselpaar: Der private Schlüssel bleibt auf deinem eigenen Rechner, der öffentliche Schlüssel wird auf dem Linux-Server hinterlegt. Nur wenn beides zusammenpasst, erlaubt SSH den Zugriff. Das ist nicht nur sicherer, sondern auch im Alltag robuster als Passwort-Login.

Wichtig für das Verständnis: Der Server ist in dieser Anleitung immer Linux. Linux und Windows sind nur zwei verschiedene Wege, wie du den Schlüssel auf deinem lokalen Rechner erzeugen kannst. Wenn du am Linux-PC arbeitest, nimmst du den Linux-Weg. Wenn du am Windows-PC sitzt, nimmst du den Windows-Weg. Ab dem Moment, in dem der öffentliche Schlüssel auf dem Server liegt, sind die weiteren Schritte für beide gleich.

Voraussetzungen

Ein Linux-Server, auf den du dich aktuell noch per Passwort anmelden kannst
Ein lokaler Rechner mit Linux oder Windows 10/11
Ein Benutzerkonto auf dem Linux-Server, idealerweise mit sudo-Rechten
Grundzugriff auf einen Editor wie nano oder vi, um später sshd_config anzupassen

Verstehen, bevor du startest: Solange der Schlüssel-Login nicht erfolgreich getestet wurde, darfst du den Passwort-Login noch nicht abschalten. Sonst sperrst du dich selbst aus.

Schritt 1: Verstehen, was Private Key und Public Key tun

Der private Schlüssel gehört nur auf deinen eigenen Rechner. Er ist dein geheimer Besitznachweis und darf niemals auf den Server kopiert oder weitergegeben werden. Der öffentliche Schlüssel ist die Gegenstelle dazu. Er darf auf dem Linux-Server in der Datei ~/.ssh/authorized_keys stehen. Wenn du später eine SSH-Verbindung aufbaust, prüft der Server: Passt der lokale private Schlüssel zu einem der hinterlegten öffentlichen Schlüssel?

Genau deshalb ist diese Methode sicherer als ein Passwort. Ein Passwort kann erraten, wiederverwendet oder geleakt werden. Ein korrekt geschützter privater Schlüssel ist deutlich schwerer anzugreifen.

Verifizieren: Du hast das Modell verstanden, wenn du diese drei Aussagen sauber trennen kannst: Der private Schlüssel bleibt lokal. Der öffentliche Schlüssel kommt auf den Linux-Server. Der Passwort-Login wird erst ganz am Ende abgeschaltet.

Schritt 2: Ed25519-Schlüsselpaar auf Linux erzeugen

Wenn dein lokaler Rechner Linux ist, öffne dort ein Terminal. Mit dem folgenden Befehl erzeugst du ein modernes Ed25519-Schlüsselpaar. Du wirst nach einem Speicherort und nach einer Passphrase gefragt. Den vorgeschlagenen Pfad kannst du in der Regel übernehmen.

ssh-keygen -t ed25519 -a 16 -C "dein-name@dein-rechner"

Bestätigst du den Standardpfad, entstehen normalerweise diese beiden Dateien:

~/.ssh/id_ed25519 – dein privater Schlüssel
~/.ssh/id_ed25519.pub – dein öffentlicher Schlüssel

Die Passphrase schützt deinen privaten Schlüssel zusätzlich. Wenn jemand deinen Laptop oder dein Home-Verzeichnis in die Hände bekommt, ist der Schlüssel ohne Passphrase deutlich leichter missbrauchbar.

Verifizieren: Prüfe lokal, ob die Dateien wirklich existieren:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Erwartung: Beide Dateien werden angezeigt. Die Datei ohne .pub ist der private Schlüssel und darf nicht weitergegeben werden.

Schritt 3: Ed25519-Schlüsselpaar auf Windows erzeugen

Wenn dein lokaler Rechner Windows 10 oder Windows 11 ist, öffne PowerShell. Der OpenSSH-Client ist in aktuellen Windows-Versionen in der Regel schon vorhanden. Dann erzeugst du das Schlüsselpaar so:

ssh-keygen -t ed25519 -a 16 -C "dein-name@dein-rechner"

Windows schlägt normalerweise den Pfad C:\Users\DEIN-NAME\.ssh\id_ed25519 vor. Auch hier entstehen wieder zwei Dateien: der private Schlüssel und die .pub-Datei als öffentlicher Schlüssel.

Verifizieren: Prüfe in PowerShell, ob beide Dateien vorhanden sind:

Get-ChildItem $env:USERPROFILE\.ssh\id_ed25519*

Erwartung: Du siehst mindestens id_ed25519 und id_ed25519.pub. Wenn PowerShell meldet, dass ssh-keygen nicht gefunden wurde, fehlt der OpenSSH-Client auf deinem System.

Schritt 4: Public Key auf den Linux-Server übertragen

Jetzt muss der öffentliche Schlüssel in die Datei authorized_keys deines Benutzerkontos auf dem Linux-Server geschrieben werden. Das Ziel ist immer:

~/.ssh/authorized_keys

Wenn du lokal auf Linux arbeitest, ist ssh-copy-id der einfachste Weg:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Wenn du auf Windows arbeitest, kannst du den öffentlichen Schlüssel mit diesem PowerShell-Befehl übertragen:

ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" < "$env:USERPROFILE\.ssh\id_ed25519.pub"

Ersetze user durch deinen echten Linux-Benutzernamen und server durch Hostname oder IP-Adresse deines Servers.

Verifizieren: Melde dich danach noch einmal normal am Linux-Server an und prüfe, ob die Datei vorhanden ist:

ls -l ~/.ssh
cat ~/.ssh/authorized_keys

Erwartung: Die Datei authorized_keys existiert. Darin steht eine lange Zeile, die mit ssh-ed25519 beginnt.

Schritt 5: Rechte auf dem Linux-Server prüfen

OpenSSH ist bei Rechten sehr streng. Wenn das Verzeichnis .ssh oder die Datei authorized_keys zu offen ist, ignoriert der Server den Schlüssel und der Login schlägt fehl. Deshalb prüfst und setzt du die Rechte jetzt bewusst:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Zur Kontrolle kannst du dir die Rechte direkt anzeigen lassen:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Verifizieren: Erwartet wird für .ssh sinngemäß drwx------ und für authorized_keys -rw-------. Wenn du stattdessen Gruppen- oder Welt-Rechte siehst, musst du die Rechte korrigieren, bevor du weitermachst.

Dieser Schritt ist der wichtigste der ganzen Anleitung. Du öffnest jetzt ein zweites Terminal oder eine zweite PowerShell-Sitzung. Die alte Verbindung zum Server bleibt offen. Dann testest du den Login mit deinem Schlüssel.

Wichtig: user@server ist nur ein Platzhalter. Du ersetzt user durch deinen echten Linux-Benutzernamen und server durch die IP-Adresse oder die Domain deines Servers.

Beispiele:

ssh admin@192.168.178.50
ssh admin@server.example.de

Wenn dein Schlüssel unter dem Standardnamen gespeichert wurde, also zum Beispiel unter ~/.ssh/id_ed25519 auf Linux oder %USERPROFILE%\.ssh\id_ed25519 auf Windows, musst du keinen Schlüsselpfad extra angeben. SSH nutzt diesen Standardschlüssel automatisch.

Nur wenn du einen anderen Dateinamen verwendest, gibst du den Schlüssel mit -i explizit an.

Auf Linux zum Beispiel so:

ssh -i ~/.ssh/id_ed25519_server1 admin@192.168.178.50

Auf Windows zum Beispiel so:

ssh -i $env:USERPROFILE\.ssh\id_ed25519_server1 admin@192.168.178.50

Wenn du eine Passphrase für den privaten Schlüssel gesetzt hast, wirst du nach dieser Passphrase gefragt. Das ist korrekt. Du solltest aber nicht mehr nach dem Server-Passwort gefragt werden.

Verifizieren: Der Test ist erfolgreich, wenn du dich in der neuen Sitzung anmelden kannst und am Server landest, ohne das Linux-Passwort des Benutzerkontos einzugeben. Wenn weiterhin das Passwort des Server-Benutzers abgefragt wird, ist der Schlüssel-Login noch nicht sauber aktiv und du darfst Schritt 7 noch nicht machen.

Erst nachdem der Test aus Schritt 6 wirklich funktioniert hat, deaktivierst du den Passwort-Login auf dem Linux-Server. Öffne die SSH-Konfiguration:

sudo nano /etc/ssh/sshd_config

Suche nach diesen Zeilen und setze sie auf die folgenden Werte. Existieren sie noch nicht oder sind auskommentiert, fügst du sie ein:

PubkeyAuthentication yes
PasswordAuthentication no

Damit sagst du dem SSH-Dienst: Schlüssel-Anmeldung ist erlaubt, Passwort-Anmeldung nicht mehr.

Verifizieren: Lies die beiden Zeilen nach dem Speichern noch einmal direkt aus der Datei aus:

grep -E "^(PubkeyAuthentication|PasswordAuthentication)" /etc/ssh/sshd_config

Erwartung: Die Ausgabe zeigt genau PubkeyAuthentication yes und PasswordAuthentication no.

Schritt 8: SSH-Dienst neu laden und Ergebnis prüfen

Die geänderte Konfiguration wird erst wirksam, wenn der Dienst neu geladen wird. Auf Debian und Ubuntu heißt der Dienst meist ssh. Auf RHEL, CentOS oder Fedora oft sshd.

Vor dem Reload kannst du die Konfiguration testen:

sudo sshd -t

Wenn der Test keine Fehlermeldung ausgibt, lädst du den Dienst neu:

sudo systemctl reload ssh

Falls deine Distribution den Dienst sshd nennt:

sudo systemctl reload sshd

Prüfe danach den Status:

sudo systemctl status ssh

oder entsprechend:

sudo systemctl status sshd

Verifizieren: Der Dienst steht auf active (running). Öffne danach noch einmal eine neue SSH-Sitzung und prüfe zwei Dinge: Der Login mit Schlüssel funktioniert weiterhin. Ein Passwort-Login wird nicht mehr angeboten. Erst dann darfst du die alte, noch geöffnete Sitzung schließen.

Schritt 9 (optional): ssh-agent unter Windows nutzen

Wenn du unter Windows nicht bei jeder Verbindung die Passphrase neu eingeben willst, kannst du den OpenSSH-Agenten verwenden. Das ist optional und ändert nichts an der eigentlichen Server-Konfiguration.

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Verifizieren: Prüfe, ob dein Schlüssel im Agenten geladen ist:

ssh-add -l

Erwartung: Dein Ed25519-Schlüssel wird in der Liste angezeigt.

Troubleshooting

Permission denied (publickey): Meist stimmen die Rechte auf .ssh oder authorized_keys nicht, oder der Public Key wurde unvollständig kopiert. Prüfe Schritt 4 und 5 nochmals.
Du wirst immer noch nach dem Server-Passwort gefragt: Dann ist der Schlüssel-Login noch nicht aktiv. Passwort-Login jetzt noch nicht abschalten. Erst prüfen, ob wirklich der richtige Schlüssel im richtigen Benutzerkonto gelandet ist.
sshd -t meldet einen Fehler: Dann stimmt etwas in sshd_config nicht. Korrigiere die genannte Zeile, bevor du den Dienst neu lädst.
systemctl reload ssh funktioniert nicht: Auf deiner Distribution heißt der Dienst eventuell sshd. Prüfe mit systemctl status sshd.
ssh-keygen fehlt unter Windows: Dann ist der OpenSSH-Client nicht installiert. Ihn kannst du unter Windows als optionales Feature nachinstallieren.
Du hast den Passwort-Login zu früh deaktiviert: Dann brauchst du die Web-Konsole oder KVM-Konsole deines Hosting-Anbieters, um den Zugang auf dem Server zu reparieren.

Häufige Fragen

Warum Ed25519 statt RSA?

Ed25519 ist heute für neue Setups die einfachste und meist sinnvollste Wahl: moderne Kryptografie, kurze Schlüssel und gute Unterstützung in aktuellen OpenSSH-Versionen.

Muss ich wirklich eine Passphrase setzen?

Für produktive Systeme: ja, nach Möglichkeit schon. Die Passphrase schützt deinen privaten Schlüssel zusätzlich, falls dein lokaler Rechner kompromittiert oder gestohlen wird.

Warum darf ich den privaten Schlüssel nie auf den Server kopieren?

Weil damit der Sicherheitsvorteil verloren geht. Der private Schlüssel ist genau das geheime Element, das nur auf deinem eigenen Gerät bleiben darf.

Was bedeuten 700 und 600 bei den Rechten?

700 bedeutet: nur der Eigentümer darf auf das Verzeichnis zugreifen. 600 bedeutet: nur der Eigentümer darf die Datei lesen und schreiben. Genau diese Strenge erwartet OpenSSH. Mehr dazu erklärt unsere Anleitung Linux-Benutzer, Gruppen und Rechte verstehen.

Kann ich denselben Public Key auf mehreren Servern nutzen?

Ja. Du kannst denselben öffentlichen Schlüssel auf mehreren Linux-Servern in authorized_keys hinterlegen. Organisatorisch ist es aber oft sinnvoll, für verschiedene Umgebungen getrennte Schlüssel zu verwenden.

Fazit

Wenn du Linux-Server dauerhaft verwalten willst, gehört SSH-Key-Authentifizierung zu den absoluten Grundlagen. Der sichere Weg ist immer gleich: Schlüsselpaar lokal erzeugen, den öffentlichen Schlüssel auf dem Linux-Server hinterlegen, Rechte prüfen, den Schlüssel-Login testen und erst ganz am Ende den Passwort-Login deaktivieren. Genau diese Reihenfolge verhindert, dass du dich selbst aussperrst.

Für den nächsten Schritt passt als Ergänzung unsere Anleitung Linux-Server absichern: UFW-Firewall und Fail2ban. Wenn dir die Rechte auf .ssh oder authorized_keys noch unklar sind, ist außerdem Linux-Benutzer, Gruppen und Rechte verstehen der passende Grundlagenartikel.

Weiterführende Anleitungen und Quellen

Quellen: ssh-keygen(1) Manpage, sshd_config(5) Manpage, ssh-copy-id(1) Manpage, Microsoft Learn – OpenSSH Key Management.