SSH-Login mit Passwort abschalten – nur noch mit Schlüssel

Wer einen Server ins Internet stellt, sieht im Log innerhalb von Stunden die ersten Anmeldeversuche: Bots probieren root, admin, ubuntu mit Passwortlisten durch. Je nach Server sind das einige tausend bis über hunderttausend Versuche pro Woche. Gegen Passwortraten gibt es eine einfache Lösung: Passwörter gar nicht mehr zulassen.

journalctl -u ssh --since "7 days ago" | grep -c "Failed password"   # wie viele Versuche?

(Bei RedHat-artigen Systemen heißt der Dienst sshd statt ssh.)

Wie funktioniert die Anmeldung mit Schlüssel?

Ein Schlüsselpaar besteht aus zwei Teilen:

• Privater Schlüssel (id_ed25519): bleibt auf deinem Rechner und wird nie kopiert oder verschickt.
• Öffentlicher Schlüssel (id_ed25519.pub): kommt auf den Server in ~/.ssh/authorized_keys.

Beim Login beweist dein Rechner, dass er den privaten Schlüssel besitzt, ohne ihn zu übertragen. Einen Schlüssel kann niemand „raten“.

Schritt 1: Schlüsselpaar erzeugen

ssh-keygen -t ed25519 -C "laptop-2026"

Eine Passphrase setzen! Sie schützt den privaten Schlüssel, falls jemand die Datei kopiert. Mit ssh-agent muss man sie nur einmal pro Sitzung eingeben.

Schritt 2: Öffentlichen Schlüssel auf den Server bringen

Solange das Passwort noch funktioniert:

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@server.example.org

Oder manuell auf dem Server:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
printf '%s\n' 'ssh-ed25519 AAAA…(dein Schlüssel) laptop-2026' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Falsche Rechte sind die häufigste Ursache, wenn der Schlüssel nicht akzeptiert wird.

Schritt 3: Schlüssel-Login getrennt testen

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -o PasswordAuthentication=no admin@server.example.org

Klappt das nicht, darf man keinesfalls weitermachen. Dann sperrt man sich später selbst aus.

Schritt 4: Passwort-Login abschalten

Auf modernen Systemen bindet /etc/ssh/sshd_config alle Dateien aus /etc/ssh/sshd_config.d/ ein. Dort legt man eine eigene Datei an, statt die Hauptdatei zu ändern:

# /etc/ssh/sshd_config.d/10-haertung.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
PermitRootLogin prohibit-password
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no

Schritt 5: Prüfen und neu laden

sshd -t                                             # Syntax prüfen (keine Ausgabe = ok)
sshd -T | grep -Ei 'passwordauth|permitroot|authenticationmethods|maxauthtries'   # tatsächlich geltende Werte
systemctl reload ssh                                # neu laden, bestehende Sitzungen bleiben offen

reload beendet bestehende Verbindungen nicht. Diese Sitzung bleibt als Rettungsanker offen, während man in einem zweiten Terminal testet.

Sicherheitsnetz: automatischer Rückweg

Bevor man neu lädt, kann man einen Timer starten, der die Änderung nach zehn Minuten selbst zurücknimmt, falls man sich ausgesperrt hat:

systemd-run --on-active=10min --unit=ssh-rollback \
  sh -c 'rm /etc/ssh/sshd_config.d/10-haertung.conf && systemctl reload ssh'

# Nach erfolgreichen Tests den Timer wieder stoppen:
systemctl stop ssh-rollback.timer

Schritt 6: Wirkung testen

ssh -o PubkeyAuthentication=no admin@server.example.org
# erwartet:  Permission denied (publickey).

Der Server bietet jetzt nur noch publickey an. Passwortraten ist sinnlos geworden.

Vorher prüfen: Nutzt jemand noch Passwörter?

journalctl -u ssh --since "30 days ago" | grep -c "Accepted publickey"
journalctl -u ssh --since "30 days ago" | grep -c "Accepted password"

Steht bei Accepted password eine Zahl größer null, gibt es Nutzer oder Skripte, die man erst auf Schlüssel umstellen muss.

Notzugang nicht vergessen

• Bei Servern von Hostern gibt es eine Konsole im Kundenportal (VNC/Rescue). Sie funktioniert unabhängig von SSH. Vorher einmal testen, ob das Root-Passwort dort geht.
• Einen zweiten Schlüssel (anderer Rechner oder ausgedruckter, sicher verwahrter Backup-Schlüssel) eintragen. Geht der Laptop kaputt, kommt man sonst nicht mehr auf den Server.
• Neuer Rechner? Der Schlüssel muss zuerst eingetragen werden, zum Beispiel über die Konsole des Hosters.

Was das bringt – und was nicht

Schützt vor	Schützt nicht vor
Passwortraten und Passwortlisten aus alten Datenlecks	Einem gestohlenen privaten Schlüssel (deshalb Passphrase)
Schwachen Passwörtern von Nutzern	Sicherheitslücken in sshd selbst (deshalb Updates)
	Anderen Diensten mit Passwort, z. B. Weboberflächen. Diese per Tunnel erreichbar machen oder mit 2FA schützen.

Die Fehlversuche im Log verschwinden nicht, aber sie sind wirkungslos. Zusammen mit fail2ban werden Angreifer außerdem nach wenigen Versuchen ausgesperrt, das spart Log-Platz und CPU.