SSH-Key-Authentifizierung ersetzt das unsichere Passwort-Login durch ein kryptographisches Schlüsselpaar: Ein privater Schlüssel bleibt lokal auf deinem Rechner, der öffentliche Schlüssel liegt auf dem Server. Nur wer den passenden privaten Schlüssel besitzt, erhält Zugang – Brute-Force-Angriffe auf Passwörter laufen ins Leere. Diese Anleitung zeigt dir, wie du auf Linux und Windows ein Ed25519-Schlüsselpaar erzeugst, den Public Key auf den Server überträgst und anschließend den Passwort-Login in der SSH-Konfiguration abschaltest.

Kurzfassung: Schlüsselpaar erzeugen mit ssh-keygen -t ed25519, Public Key mit ssh-copy-id (Linux) oder manuell per PowerShell (Windows) in ~/.ssh/authorized_keys eintragen, dann in /etc/ssh/sshd_config PasswordAuthentication no setzen und den SSH-Dienst mit systemctl reload ssh (Debian/Ubuntu) bzw. systemctl reload sshd (RHEL/CentOS) neu laden.

Voraussetzungen

Zugang zum Remote-Server per SSH (noch mit Passwort möglich)
Linux-Client oder Windows 10 (April 2018 Update) / Windows 11 mit eingebautem OpenSSH-Client
Sudo-Rechte auf dem Remote-Server, um /etc/ssh/sshd_config zu bearbeiten
Auf Windows: PowerShell 5.1 oder neuer (vorinstalliert ab Windows 10)

Schritt 1: Ed25519-Schlüsselpaar erzeugen (Linux)

Öffne ein Terminal auf deinem lokalen Linux-Rechner. Der Befehl erzeugt ein Ed25519-Schlüsselpaar mit Kommentar und 16 KDF-Runden für die Passphrase-Verschlüsselung. Gib auf Nachfrage eine starke Passphrase ein – leer lassen ist technisch möglich, aber für Produktivsysteme nicht empfohlen.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C 'dein-name@dein-rechner' -a 16

Das Ergebnis sind zwei Dateien: ~/.ssh/id_ed25519 (privater Schlüssel, geheim halten!) und ~/.ssh/id_ed25519.pub (öffentlicher Schlüssel).

Schritt 2: Ed25519-Schlüsselpaar erzeugen (Windows)

Öffne PowerShell (kein Administrator nötig). Der OpenSSH-Client ist ab Windows 10 April 2018 Update eingebaut; ssh-keygen ist direkt verfügbar. Der Befehl legt das Schlüsselpaar unter %USERPROFILE%\.ssh\ ab.

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\id_ed25519 -C 'dein-name@dein-rechner' -a 16

Alternativ reicht ssh-keygen -t ed25519 ohne weitere Parameter – der interaktive Assistent fragt Pfad und Passphrase ab. Die Dateien liegen dann unter C:\Users\DEIN-NAME\.ssh\id_ed25519 und id_ed25519.pub.

Schritt 3: Public Key auf den Server übertragen

Jetzt muss der öffentliche Schlüssel in die Datei ~/.ssh/authorized_keys des Remote-Benutzers eingetragen werden. Es gibt zwei Wege:

Linux-Client: ssh-copy-id (empfohlen)

ssh-copy-id legt das .ssh-Verzeichnis und authorized_keys automatisch an und setzt die richtigen Rechte.

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

Linux-Client: manuell (Fallback)

Falls ssh-copy-id nicht verfügbar ist:

cat ~/.ssh/id_ed25519.pub | ssh user@remote.host 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Windows-Client: manuell per PowerShell

ssh-copy-id ist auf Windows nicht verfügbar. Nutze stattdessen diesen PowerShell-Befehl, der den Public Key direkt in die authorized_keys-Datei des Remote-Servers schreibt:

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

Schritt 4: Dateirechte auf dem Server prüfen

SSH ist sicherheitsbewusst: Sind die Rechte auf .ssh oder authorized_keys zu offen, verweigert der SSH-Daemon die Schlüsselprüfung und du erhältst Permission denied. Melde dich per SSH am Server an (noch mit Passwort, falls nötig) und setze die Rechte:

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

Das .ssh-Verzeichnis braucht genau 700 (nur der Eigentümer darf lesen, schreiben, betreten), authorized_keys genau 600 (nur der Eigentümer darf lesen und schreiben). Auch der private Schlüssel muss 600 haben – andernfalls weigert sich der SSH-Client, ihn zu nutzen (UNPROTECTED PRIVATE KEY FILE).

Schritt 5: Verbindung mit SSH-Key testen

Bevor du den Passwort-Login abschaltest, prüfe unbedingt, ob die Key-Authentifizierung bereits funktioniert. Öffne ein neues Terminal und verbinde dich:

ssh -i ~/.ssh/id_ed25519 user@remote.host

Auf Windows in PowerShell:

ssh -i $env:USERPROFILE\.ssh\id_ed25519 user@remote.host

Wirst du nach der Passphrase des Schlüssels gefragt (nicht nach dem Server-Passwort), ist der Key korrekt hinterlegt. Melde dich an und fahre dann mit Schritt 6 fort. Tritt stattdessen Permission denied (publickey) auf, prüfe die Dateirechte aus Schritt 4 und ob der richtige Public Key eingetragen ist.

Erst jetzt – wenn der Key-Login sicher funktioniert – deaktivierst du den Passwort-Login. Öffne /etc/ssh/sshd_config mit einem Editor deiner Wahl. Auf Debian/Ubuntu:

sudo nano /etc/ssh/sshd_config

Auf RHEL/CentOS:

sudo vi /etc/ssh/sshd_config

Suche nach den folgenden Zeilen und setze die Werte exakt so. Gibt es die Zeile noch nicht oder steht ein # davor, füge sie neu ein bzw. entferne das Kommentarzeichen:

PubkeyAuthentication yes
PasswordAuthentication no

Achte auf korrekte Groß-/Kleinschreibung und keine ungewollten Leerzeichen. Ein Syntaxfehler verhindert den Neustart des SSH-Daemons.

Schritt 7: SSH-Dienst neu laden

Die neue Konfiguration wird erst aktiv, wenn du den SSH-Dienst neu lädst. Der Service-Name unterscheidet sich je nach Distribution:

Debian / Ubuntu (Service heißt ssh, nicht sshd!):

sudo systemctl reload ssh

RHEL / CentOS / Fedora:

sudo systemctl reload sshd

Prüfe danach den Status, um Syntaxfehler in der Config zu erkennen:

sudo systemctl status ssh

Zeigt der Status active (running), ist alles in Ordnung. Öffne jetzt in einem separaten Terminal eine neue SSH-Verbindung und bestätige, dass der Login mit Key funktioniert und das Passwort-Login nicht mehr akzeptiert wird – bevor du das alte Terminal-Fenster schließt.

Schritt 8 (optional): ssh-agent unter Windows einrichten

Unter Windows kannst du den ssh-agent-Dienst aktivieren, damit du die Passphrase deines Schlüssels nicht bei jeder Verbindung neu eingeben musst. Dieser Schritt erfordert ein PowerShell-Fenster mit Administratorrechten:

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

Nach dem einmaligen ssh-add merkt sich der Dienst den entschlüsselten Schlüssel für die aktuelle Windows-Sitzung. Zukünftige SSH-Verbindungen benötigen dann keine Passphrase-Eingabe mehr.

Troubleshooting

Permission denied (publickey): Der Server akzeptiert den Key nicht. Prüfe mit chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys, ob die Rechte korrekt sind. Vergewissere dich, dass der richtige Public Key vollständig (als eine Zeile) in authorized_keys steht.
UNPROTECTED PRIVATE KEY FILE: Der private Schlüssel auf dem Client hat zu offene Rechte (z. B. 644). Abhilfe auf Linux: chmod 600 ~/.ssh/id_ed25519. Auf Windows: Datei-Eigenschaften öffnen und Berechtigungen auf den eigenen Benutzer beschränken.
ssh-keygen nicht gefunden (Windows): Der OpenSSH-Client ist nicht installiert. Gehe zu Einstellungen → Apps → Optionale Features → OpenSSH-Client hinzufügen. Gilt für Windows 10 vor dem April 2018 Update.
systemctl reload sshd schlägt auf Debian/Ubuntu fehl: Der Service heißt dort ssh, nicht sshd. Nutze sudo systemctl reload ssh.
Syntaxfehler in sshd_config: Der Dienst startet nicht. Führe sudo sshd -t aus – das prüft die Konfiguration ohne Neustart und zeigt die fehlerhafte Zeile an.
Passwort-Login deaktiviert, Key funktioniert nicht: Du sperrst dich aus. Repariere den Zugang über die Konsole des Hosting-Anbieters (KVM/VNC). Deshalb: immer erst Key testen, dann Passwort-Login abschalten.
ssh-copy-id auf Windows nicht verfügbar: Das Tool existiert nur auf Linux/macOS. Nutze stattdessen den PowerShell-Befehl aus Schritt 3.

Häufige Fragen

Warum Ed25519 statt RSA?

Ed25519 ist der aktuelle Standard: kürzere Schlüssel (256 Bit), schnellere Operationen und mindestens gleichwertige Sicherheit wie RSA mit 3072–4096 Bit. Neuere OpenSSH-Versionen nutzen Ed25519 als Standard, wenn kein -t-Flag angegeben wird.

Muss ich eine Passphrase für den privaten Schlüssel setzen?

Technisch nein, aber für Produktivserver dringend empfohlen. Ohne Passphrase ist der private Schlüssel ungeschützt, wenn jemand Zugriff auf deine lokale Festplatte bekommt. Mit ssh-agent (Linux/macOS) oder dem Windows-OpenSSH-Agent musst du die Passphrase nur einmal pro Sitzung eingeben.

Was bedeuten die Rechte 700 und 600?

700 auf .ssh bedeutet: nur der Eigentümer darf lesen, schreiben und das Verzeichnis betreten (drwx------). 600 auf authorized_keys und den privaten Schlüssel bedeutet: nur der Eigentümer darf lesen und schreiben (-rw-------). Der SSH-Daemon verweigert die Schlüsselprüfung bei zu offenen Rechten als Sicherheitsmaßnahme. Weitere Informationen zu Linux-Rechten findest du in unserer Anleitung zu Dateirechten, chmod und chown.

Kann ich mehrere SSH-Keys für verschiedene Server verwenden?

Ja. Erzeuge für jeden Verwendungszweck einen eigenen Schlüssel mit unterschiedlichem Dateinamen, z. B. ~/.ssh/id_ed25519_server1. In ~/.ssh/config kannst du pro Host festlegen, welcher Schlüssel verwendet wird:

Host server1.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_server1

Wie übertrage ich den Key auf mehrere Server?

Führe ssh-copy-id -i ~/.ssh/id_ed25519.pub user@SERVER für jeden Server einzeln aus. Den gleichen Public Key kannst du beliebig oft auf verschiedenen Servern in authorized_keys eintragen.

Was ist der Unterschied zwischen systemctl reload und restart?

reload lässt den SSH-Daemon weiterlaufen und lädt nur die Konfiguration neu – bestehende Verbindungen werden nicht unterbrochen. restart beendet und startet den Dienst neu – bestehende SSH-Sessions werden getrennt. Für Config-Änderungen ist reload die sichere Wahl.

Fazit

SSH-Key-Authentifizierung ist eine der effektivsten Maßnahmen, um SSH-Zugänge zu sichern. Das Verfahren ist auf Linux und Windows gleichermaßen verfügbar und in wenigen Minuten eingerichtet. Der entscheidende Punkt: erst den Key-Login testen, dann den Passwort-Login abschalten – so sperrst du dich nicht aus. Mit Ed25519 und einer starken Passphrase bist du gegenüber Brute-Force-Angriffen und gestohlenen Passwörtern gut geschützt.

Für weiterführende Absicherung des SSH-Dienstes empfiehlt sich als nächster Schritt die Einrichtung eines systemd-Services für automatische Starts – mehr dazu in unserer Anleitung zu systemd-Services.

Weiterführende Anleitungen und Quellen

Linux-Dateirechte: chmod, chown und sudo verstehen – Hintergrundwissen zu den Rechten 700/600
systemd-Service erstellen und verwalten – SSH-Dienst dauerhaft konfigurieren
Cron und Crontab: Grundlagen für Linux – Automatisierung auf Linux-Servern
Alle Linux-Anleitungen bei Schönfelder EDV

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