Von allen Maßnahmen auf dieser Seite hat diese das beste Verhältnis von Aufwand zu Wirkung: Sie dauert zehn Minuten und schließt den Weg, über den die meisten Server tatsächlich übernommen werden.
Ein Server mit aktivem Passwort-Login bekommt ab der ersten Minute automatisierte Anmeldeversuche. Das ist kein gezielter Angriff, sondern Grundrauschen, aber es genügt ein schwaches oder anderswo geleaktes Passwort, und der Zugang steht offen. Solange dieser Weg offen ist, sind alle weiteren Maßnahmen zweitrangig.
Wie weit ein Zugang trägt#
Ein Passwort ist ein Geheimnis, das übertragen wird und das Menschen sich merken müssen. Beides ist das Problem: Es kann erraten, wiederverwendet oder anderswo geleakt werden.
Ein Schlüsselpaar löst beides. Der private Teil verlässt deinen Rechner nie; übertragen wird nur eine Signatur über eine Zufallsaufgabe des Servers. Es gibt nichts, was ein Angreifer mitschneiden oder erraten könnte.
Schritt 1: Schlüssel erzeugen#
Auf deinem eigenen Rechner, nicht auf dem Server:
ssh-keygen -t ed25519 -C "mauri@laptop-2026"Ed25519 ist der Standardfall: kurz, schnell, keine Parameter, bei denen man etwas falsch machen kann. Die Passphrase-Abfrage nicht überspringen, sie ist das, was den Schlüssel schützt, falls der Laptop wegkommt. Der Komfortverlust ist dank ssh-agent genau einmal pro Sitzung spürbar.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 # macOS: ssh-add --apple-use-keychainSchritt 2: Öffentlichen Teil auf den Server bringen#
ssh-copy-id [email protected]Falls ssh-copy-id nicht verfügbar ist, geht es auch von Hand:
cat ~/.ssh/id_ed25519.pub | ssh [email protected] \
'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'Die Rechte sind nicht Kosmetik: Ist ~/.ssh für die Gruppe oder andere schreibbar, verweigert der SSH-Dienst den Schlüssel kommentarlos und man sucht den Fehler an der falschen Stelle.
Schritt 3: Testen, bevor irgendetwas abgeschaltet wird#
In einem neuen Fenster, während die alte Sitzung offen bleibt:
ssh [email protected]Wenn diese Anmeldung ohne Passwortabfrage durchläuft, ist Schritt 4 gefahrlos. Wenn nicht, hilft die ausführliche Ausgabe:
ssh -v [email protected] 2>&1 | grep -i 'offering\|accepted\|denied'Schritt 4: Passwort-Login abschalten#
Eigene Datei im Unterverzeichnis statt Änderung an der Hauptdatei, dann fragt kein Paket-Update, ob du deine Konfiguration behalten willst:
# /etc/ssh/sshd_config.d/10-haertung.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
MaxAuthTries 3
Beide Passwort-Zeilen sind nötig. KbdInteractiveAuthentication deckt den tastatur-interaktiven Weg ab, über den sich sonst doch ein Passwortdialog öffnet, der häufigste Grund dafür, dass „abgeschaltet“ nicht abgeschaltet ist.
sudo sshd -t && sudo systemctl reload sshsshd -t prüft die Syntax und ist der Unterschied zwischen „Tippfehler bemerkt“ und „ausgesperrt“. reload lässt bestehende Sitzungen offen.
Halte während der ganzen Änderung eine zweite, bereits angemeldete Sitzung offen und teste den neuen Zugang in einem dritten Fenster. Zusätzlich: Die serielle Konsole oder VNC im Kundenpanel einmal ausprobiert haben, bevor du sie brauchst. Die Entdeckung, dass die Konsole ein Applet von vorgestern verlangt, macht man besser an einem entspannten Nachmittag.
Prüfen, dass es wirklich zu ist#
# Muss abgelehnt werden
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]
# Was der Dienst tatsächlich geladen hat (nicht, was in der Datei steht)
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|kbdinteractive'Die zweite Zeile ist die wichtige. sshd -T zeigt die effektive Konfiguration inklusive aller eingelesenen Dateien, dort sieht man auch, wenn eine spätere Datei die eigene Einstellung wieder überschreibt.
Was sich danach in den Protokollen ändert#
sudo journalctl -u ssh --since "24 hours ago" | grep -c "Invalid user"Die Zahl bleibt zunächst hoch, die Versuche hören nicht auf, sie laufen nur ins Leere. Wen der Lärm in den Protokollen stört, findet in Fail2ban: Lärmschutz, kein Schutzwall die Einordnung, warum das eine Komfort- und keine Sicherheitsmaßnahme ist.
Wenn mehrere Menschen Zugang brauchen#
Ein Schlüssel pro Person und Gerät, nicht ein geteilter Schlüssel für alle. Der Unterschied zeigt sich an dem Tag, an dem jemand geht oder ein Laptop wegkommt: Dann entfernst du eine Zeile aus authorized_keys, statt bei allen neue Schlüssel zu verteilen.
# Wer hat aktuell Zugang?
cat ~/.ssh/authorized_keys | awk '{print $3}'Der Kommentar am Ende jeder Zeile ist die Dokumentation. mauri@laptop-2026 verrät in zwei Jahren, welche Zeile weg kann. user@host verrät nichts.
Danach#
Der Zugang ist damit geschlossen. Die nächste Frage ist, was von außen überhaupt erreichbar sein muss, dazu Eingehend dichtmachen. Und die Maßnahme mit der zweitgrößten Wirkung ist automatische Sicherheitsupdates, weil die meisten Übernahmen über bekannte, längst gepatchte Lücken laufen.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
