SSH-Key-Authentifizierung gehört zu den wichtigsten Grundmaßnahmen für jeden Linux-Server. Statt sich mit einem Passwort anzumelden, nutzen Sie ein Schlüsselpaar: Der private Schlüssel bleibt auf Ihrem eigenen Rechner, der öffentliche Schlüssel liegt auf dem Linux-Server. Nur wenn beide zusammenpassen, erlaubt SSH den Zugriff. Das ist sicherer als ein Passwort-Login und im Alltag bequemer.

Wichtig für das Verständnis: Der Server ist in dieser Anleitung immer Linux. Linux und Windows sind nur zwei Wege, den Schlüssel auf Ihrem lokalen Rechner zu erzeugen. Arbeiten Sie am Linux-PC, folgen Sie dem Linux-Weg, am Windows-PC dem Windows-Weg. Sobald der öffentliche Schlüssel auf dem Server liegt, sind die weiteren Schritte für beide gleich.

Voraussetzungen

Ein Linux-Server, auf dem Sie sich aktuell noch per Passwort anmelden können
Ein lokaler Rechner mit Linux oder Windows 10/11 (OpenSSH-Client ab Werk bzw. als optionales Feature)
Ein Benutzerkonto auf dem Linux-Server mit sudo-Rechten
Ein Editor wie nano oder vi, um sshd_config anzupassen
Bei gemieteten Servern: Zugang zur Web- oder KVM-Konsole des Anbieters als Notzugang

Wichtig: Solange der Schlüssel-Login nicht erfolgreich getestet ist, schalten Sie den Passwort-Login nicht ab. Sonst sperren Sie sich selbst aus.

Hardware für diese Anleitung

Enthält Werbelinks

FIDO2-Sicherheitsschlüssel	Phishing-sicherer als Codes aus einer App. Immer zwei kaufen: einen für den Alltag, einen als Reserve an einem sicheren Ort.	Sicherheitsschlüssel bei Amazon (Werbelink)

Die Anleitung funktioniert mit jedem FIDO2-Schlüssel. * Werbelink

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

Der private Schlüssel gehört nur auf Ihren eigenen Rechner. Er ist Ihr geheimer Besitznachweis und darf nie auf den Server kopiert oder weitergegeben werden. Der öffentliche Schlüssel ist die Gegenstelle dazu und steht auf dem Linux-Server in der Datei ~/.ssh/authorized_keys. Beim Verbindungsaufbau prüft der Server, ob Ihr lokaler privater Schlüssel zu einem der hinterlegten öffentlichen Schlüssel passt.

Deshalb ist diese Methode sicherer als ein Passwort. Ein Passwort kann erraten, wiederverwendet oder abgegriffen werden. Ein geschützter privater Schlüssel verlässt Ihren Rechner nie.

Verifizieren: Sie können drei Aussagen klar trennen: 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

Ist Ihr lokaler Rechner ein Linux-System, öffnen Sie dort ein Terminal. Der folgende Befehl erzeugt ein Ed25519-Schlüsselpaar. Sie werden nach Speicherort und Passphrase gefragt. Den vorgeschlagenen Pfad können Sie in der Regel übernehmen.

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

Mit dem Standardpfad entstehen diese beiden Dateien:

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

Die Passphrase schützt Ihren privaten Schlüssel zusätzlich. Gelangt jemand an Ihren Laptop oder Ihr Home-Verzeichnis, ist ein Schlüssel ohne Passphrase sofort nutzbar.

Verifizieren: Prüfen Sie lokal, ob die Dateien 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

Ist Ihr lokaler Rechner ein Windows-10- oder Windows-11-System, öffnen Sie PowerShell. Der OpenSSH-Client ist in aktuellen Windows-Versionen in der Regel vorhanden. Erzeugen Sie das Schlüsselpaar so:

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

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

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

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

Erwartung: Sie sehen id_ed25519 und id_ed25519.pub. Meldet PowerShell, dass ssh-keygen nicht gefunden wurde, fehlt der OpenSSH-Client.

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

Jetzt kommt der öffentliche Schlüssel in die Datei authorized_keys Ihres Benutzerkontos auf dem Linux-Server. Das Ziel ist immer:

~/.ssh/authorized_keys

Unter Linux ist ssh-copy-id der einfachste Weg:

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

Unter Windows gibt es ssh-copy-id nicht. Übertragen Sie den öffentlichen Schlüssel per Pipeline, denn PowerShell kennt den Eingabeoperator < nicht:

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys"

Ersetzen Sie user durch Ihren Linux-Benutzernamen und server durch Hostname oder IP-Adresse Ihres Servers.

Verifizieren: Melden Sie sich noch einmal normal am Linux-Server an und prüfen Sie, ob die Datei vorhanden ist:

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

Erwartung: Die Datei authorized_keys existiert und enthält eine lange Zeile, die mit ssh-ed25519 beginnt.

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

OpenSSH ist bei Rechten streng. Sind das Verzeichnis .ssh oder die Datei authorized_keys für andere beschreibbar, ignoriert der Server den Schlüssel und der Login schlägt fehl. Setzen Sie die Rechte deshalb ausdrücklich:

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

Zur Kontrolle zeigen Sie die Rechte an:

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

Verifizieren: .ssh zeigt drwx------, authorized_keys zeigt -rw-------, und beide gehören Ihrem Benutzer. Sehen Sie Gruppen- oder Welt-Rechte, korrigieren Sie diese, bevor Sie weitermachen.

Dieser Schritt ist der wichtigste der Anleitung. Öffnen Sie ein zweites Terminal bzw. eine zweite PowerShell-Sitzung. Die bestehende Verbindung zum Server bleibt offen. Testen Sie dann den Login mit Ihrem Schlüssel.

user@server ist ein Platzhalter. Ersetzen Sie user durch Ihren Linux-Benutzernamen und server durch die IP-Adresse oder die Domain Ihres Servers.

Beispiele:

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

Liegt Ihr Schlüssel unter dem Standardnamen, also ~/.ssh/id_ed25519 unter Linux oder %USERPROFILE%\.ssh\id_ed25519 unter Windows, müssen Sie keinen Schlüsselpfad angeben. SSH nutzt diesen Schlüssel automatisch.

Nur bei einem anderen Dateinamen geben Sie den Schlüssel mit -i an.

Unter Linux:

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

Unter Windows:

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

Haben Sie eine Passphrase gesetzt, fragt SSH nach dieser Passphrase. Das ist korrekt. Nach dem Server-Passwort dürfen Sie nicht mehr gefragt werden.

Verifizieren: Sie landen in der neuen Sitzung auf dem Server, ohne das Linux-Passwort des Benutzerkontos einzugeben. Wird weiterhin das Server-Passwort abgefragt, ist der Schlüssel-Login noch nicht aktiv. Führen Sie Schritt 7 dann noch nicht aus.

Erst wenn der Test aus Schritt 6 funktioniert, deaktivieren Sie den Passwort-Login. Prüfen Sie zuerst, ob Dateien in /etc/ssh/sshd_config.d/ den Wert bereits setzen:

sudo grep -ri passwordauthentication /etc/ssh/sshd_config.d/

OpenSSH übernimmt bei doppelten Angaben den ersten gefundenen Wert, und die Dateien aus sshd_config.d werden am Anfang von sshd_config eingebunden. Viele Cloud-Images (zum Beispiel 50-cloud-init.conf unter Ubuntu) setzen dort PasswordAuthentication yes. Ändern Sie in diesem Fall den Wert in der gefundenen Datei auf no.

Öffnen Sie anschließend die Hauptkonfiguration:

sudo nano /etc/ssh/sshd_config

Setzen Sie diese Zeilen auf die folgenden Werte. Fehlen sie oder sind sie auskommentiert, fügen Sie sie ein:

PubkeyAuthentication yes
PasswordAuthentication no

Damit erlaubt der SSH-Dienst die Anmeldung per Schlüssel, aber nicht mehr per Passwort.

Verifizieren: Lassen Sie sich die tatsächlich wirksame Konfiguration ausgeben:

sudo sshd -T | grep -E "^(pubkeyauthentication|passwordauthentication)"

Erwartung: pubkeyauthentication yes und passwordauthentication no. Ein grep nur auf sshd_config reicht nicht, weil er überschreibende Dateien aus sshd_config.d nicht berücksichtigt.

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

Die geänderte Konfiguration wirkt erst nach einem Reload des Dienstes. Auf Debian und Ubuntu heißt der Dienst ssh, auf RHEL, Rocky Linux oder Fedora sshd.

Testen Sie vor dem Reload die Konfiguration:

sudo sshd -t

Gibt der Test keine Fehlermeldung aus, laden Sie den Dienst neu:

sudo systemctl reload ssh

Heißt der Dienst auf Ihrer Distribution sshd:

sudo systemctl reload sshd

Prüfen Sie danach den Status:

sudo systemctl status ssh

oder entsprechend:

sudo systemctl status sshd

Verifizieren: Der Dienst steht auf active (running). Öffnen Sie eine neue SSH-Sitzung mit Schlüssel, sie funktioniert weiterhin. Testen Sie dann den Passwort-Weg gezielt mit ssh -o PubkeyAuthentication=no user@server: Erwartet ist Permission denied (publickey). Erst dann schließen Sie die alte Sitzung.

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

Möchten Sie unter Windows nicht bei jeder Verbindung die Passphrase eingeben, verwenden Sie den OpenSSH-Agenten. Das ist optional und ändert nichts an der Server-Konfiguration. Die ersten beiden Befehle benötigen eine PowerShell mit Administratorrechten.

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

Verifizieren: Prüfen Sie, ob Ihr Schlüssel im Agenten geladen ist:

ssh-add -l

Erwartung: Ihr Ed25519-Schlüssel erscheint in der Liste.

Troubleshooting

Permission denied (publickey): Meist stimmen die Rechte auf .ssh oder authorized_keys nicht, oder der Public Key wurde unvollständig kopiert. Prüfen Sie Schritt 4 und 5.
PowerShell meldet „Der Operator < ist für zukünftige Versionen reserviert“: Sie haben eine Anleitung mit Bash-Umleitung verwendet. Nutzen Sie die Pipeline aus Schritt 4.
Sie werden weiterhin nach dem Server-Passwort gefragt: Der Schlüssel-Login ist noch nicht aktiv. Schalten Sie den Passwort-Login noch nicht ab und prüfen Sie, ob der richtige Schlüssel im richtigen Benutzerkonto liegt. Details zeigt ssh -v user@server.
Passwort-Login funktioniert trotz PasswordAuthentication no: Eine Datei in /etc/ssh/sshd_config.d/ setzt den Wert vorher auf yes. Prüfen Sie mit sudo sshd -T (Schritt 7).
sshd -t meldet einen Fehler: In sshd_config stimmt eine Zeile nicht. Korrigieren Sie die genannte Zeile, bevor Sie den Dienst neu laden.
systemctl reload ssh funktioniert nicht: Auf Ihrer Distribution heißt der Dienst vermutlich sshd. Prüfen Sie mit systemctl status sshd.
ssh-keygen fehlt unter Windows: Der OpenSSH-Client ist nicht installiert. Sie installieren ihn unter Windows als optionales Feature nach.
Passwort-Login zu früh deaktiviert: Nutzen Sie die Web- oder KVM-Konsole Ihres Hosting-Anbieters, um den Zugang auf dem Server zu reparieren.

Häufige Fragen

Warum Ed25519 statt RSA?

Ed25519 ist für neue Setups die einfachste Wahl: moderne Kryptografie, kurze Schlüssel und Unterstützung in allen aktuellen OpenSSH-Versionen. RSA brauchen Sie nur noch für sehr alte Gegenstellen.

Muss ich wirklich eine Passphrase setzen?

Für produktive Systeme: ja. Die Passphrase schützt Ihren privaten Schlüssel, falls Ihr lokaler Rechner kompromittiert oder gestohlen wird. Mit dem ssh-agent (Schritt 9) geben Sie sie nur einmal pro Sitzung ein.

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

Weil damit der Sicherheitsvorteil verloren geht. Der private Schlüssel ist das geheime Element, das nur auf Ihrem 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. 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. Sie können denselben öffentlichen Schlüssel auf mehreren Linux-Servern in authorized_keys hinterlegen. Organisatorisch ist es oft sinnvoll, für getrennte Umgebungen getrennte Schlüssel zu verwenden.

Fazit

Wer Linux-Server dauerhaft verwaltet, braucht SSH-Key-Authentifizierung. Der sichere Weg ist immer gleich: Schlüsselpaar lokal erzeugen, öffentlichen Schlüssel auf dem Server hinterlegen, Rechte prüfen, Schlüssel-Login testen und erst am Ende den Passwort-Login deaktivieren und mit sshd -T kontrollieren. Diese Reihenfolge verhindert, dass Sie sich aussperren.

Als nächster Schritt passt unsere Anleitung Linux-Server absichern: UFW-Firewall und Fail2ban. Sind Ihnen die Rechte auf .ssh oder authorized_keys noch unklar, hilft Linux-Benutzer, Gruppen und Rechte verstehen.

Weiterführende Anleitungen und Quellen

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