Wenige Minuten nachdem ein Server online geht, klopfen die ersten Bots an und probieren Passwörter durch – rund um die Uhr, vollautomatisch. Gegen dieses Dauerfeuer gibt es eine Lösung, die besser ist als jedes noch so lange Passwort: SSH-Keys. Einmal eingerichtet, läuft jeder Brute-Force-Versuch ins Leere, und du loggst dich nebenbei auch noch bequemer ein.
Warum Keys jedes Passwort schlagen
Ein SSH-Key ist ein kryptografisches Schlüsselpaar: Der private Schlüssel bleibt auf deinem Rechner und verlässt ihn nie, der öffentliche Schlüssel wird auf dem Server hinterlegt. Beim Login beweist dein Rechner rechnerisch, dass er den privaten Schlüssel besitzt – ohne dass ein Geheimnis übertragen wird.
Damit sind die zwei größten Schwächen von Passwörtern beseitigt: Ein Key lässt sich nicht erraten (die Schlüssellänge macht Durchprobieren aussichtslos) und nicht abphishen (es gibt nichts, was sich auf einer falschen Seite eintippen ließe).
Schritt 1: Schlüsselpaar erzeugen
Windows (ab Windows 10), macOS und Linux bringen den passenden Befehl bereits mit. Öffne ein Terminal bzw. PowerShell und erzeuge ein modernes ed25519-Schlüsselpaar:
ssh-keygen -t ed25519 -C "mein-laptop"
Den Speicherort bestätigst du mit Enter. Die anschließend abgefragte Passphrase solltest du setzen: Sie verschlüsselt den privaten Schlüssel auf deiner Platte – falls dein Rechner gestohlen wird, ist der Key allein wertlos. Damit du sie nicht bei jedem Login eintippen musst, merkt sie sich der SSH-Agent deines Systems.
Danach liegen im Ordner ~/.ssh/ zwei Dateien: id_ed25519 (privat – niemals weitergeben, nirgendwo hochladen) und id_ed25519.pub (öffentlich – die kommt gleich auf den Server).
Schritt 2: Öffentlichen Schlüssel auf den Server bringen
Unter Linux und macOS erledigt das ein einziger Befehl, der auch gleich die Dateirechte korrekt setzt:
ssh-copy-id benutzer@server-ip
Unter Windows fehlt ssh-copy-id – dort übernimmt diese PowerShell-Zeile dieselbe Aufgabe:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Beide Varianten hängen deinen öffentlichen Schlüssel an die Datei ~/.ssh/authorized_keys auf dem Server an. Dort darf pro Zeile ein Key stehen – so kannst du später problemlos einen zweiten Rechner berechtigen.
Schritt 3: Testen – bevor du irgendetwas abschaltest
Öffne ein neues Terminalfenster und verbinde dich wie gewohnt:
ssh benutzer@server-ip
Wirst du ohne Server-Passwort eingeloggt (höchstens die Key-Passphrase wird lokal abgefragt), funktioniert der Key-Login.
Faustregel: Erst testen, dann aussperren. Lass die alte SSH-Session so lange geöffnet, bis der Key-Login in einer zweiten Session nachweislich funktioniert – sie ist dein Rettungsanker bei Tippfehlern in der Konfiguration.
Schritt 4: Passwort-Login abschalten
Jetzt kommt der Schritt, der die Bots endgültig aussperrt. Öffne die SSH-Konfiguration auf dem Server:
sudo nano /etc/ssh/sshd_config
Setze (bzw. ergänze) diese Zeilen:
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
Die ersten beiden Zeilen schalten sämtliche Passwort-Verfahren ab, die dritte erlaubt Root-Logins nur noch per Key.
Ein Stolperstein auf vielen Cloud- und Hoster-Images: Im Ordner /etc/ssh/sshd_config.d/ liegen oft zusätzliche Konfigurationsdateien, die deine Einstellungen wieder überschreiben. Prüfe das mit einem Griff:
sudo grep -r "PasswordAuthentication" /etc/ssh/
Taucht dort irgendwo ein PasswordAuthentication yes auf (typisch: 50-cloud-init.conf), ändere es auch in dieser Datei. Danach Konfiguration prüfen und den Dienst neu laden:
sudo sshd -t && sudo systemctl restart ssh
Gibt sshd -t nichts aus, ist die Syntax in Ordnung. Teste nun in einem weiteren Fenster, dass der Login per Key weiterhin klappt – und dass ein Login mit Passwort abgelehnt wird.
Wenn doch etwas schiefgeht
Solltest du dich trotz aller Vorsicht aussperren, ist nicht alles verloren: Praktisch jeder Hoster bietet im Control Panel eine (VNC-)Konsole, die direkt auf den Server führt – wie Bildschirm und Tastatur am physischen Gerät. Darüber machst du die Änderung rückgängig und startest den zweiten Anlauf.
Fazit
Key erzeugen, hinterlegen, testen, Passwort-Login abschalten – vier Schritte, die die häufigste Angriffsfläche eines Servers komplett schließen. Automatisierte Passwort-Versuche laufen ab sofort ins Leere. Der Key-Login ist damit der wichtigste Baustein der Grundabsicherung; welche Schritte als Nächstes sinnvoll sind – Firewall, Updates, Backups – zeigt der Leitfaden VPS absichern: 7 Schritte. Und warum sich gegen Angriffe auf die Leitung selbst der beste Login nicht wehren kann, erklärt der Beitrag Was ist ein DDoS-Angriff?.