SSH absichern: So machst du den Fernzugriff auf deine Linux-Server dicht
Schlüssel statt Passwort, Root-Login aus, Fail2ban davor: Damit sind die automatisierten Angriffe erledigt, die den Großteil der Logeinträge erzeugen. Der Rest ist Feinschliff, den du Option für Option in der sshd_config setzt.
Warum die Standardkonfiguration nicht reicht
Ein frisch installierter OpenSSH-Server ist bewusst kompatibel konfiguriert und nicht auf maximale Härte ausgelegt. Passwort-Authentifizierung ist meist aktiv, die Distribution erlaubt je nach Paket den root-Login mindestens per Key, und die zulässigen Algorithmen decken auch ältere Clients ab. Sobald der Port 22 aus dem Internet erreichbar ist, laufen innerhalb weniger Minuten die ersten Login-Versuche gegen Standardkonten wie root, admin, ubuntu oder git.
In der Praxis scheitert Härtung selten am Wissen, sondern an der Reihenfolge. Typisch ist, dass PasswordAuthentication abgeschaltet wird, bevor der eigene Public Key tatsächlich in der authorized_keys liegt, dass Änderungen direkt in der sshd_config landen statt in einem eigenen Drop-in unter /etc/ssh/sshd_config.d/, oder dass ein Include am Dateianfang die eigenen Einstellungen still überschreibt. Auch die aktive Session wird gerne geschlossen, bevor eine zweite Verbindung die neue Konfiguration bestätigt hat.
Dazu kommen Annahmen, die sich hartnäckig halten. Ein anderer Port entfernt zwar Rauschen aus den Logs, ist aber keine Sicherheitsmaßnahme gegen einen gezielten Scan. Fail2Ban schützt gegen Rate-basiertes Raten, nicht gegen einen gestohlenen Schlüssel ohne Passphrase. Und ein sauber gehärteter sshd nützt wenig, wenn danach jeder Benutzer per ~/.ssh/config Agent-Forwarding auf beliebige Hosts weiterreicht.
Härtung in sechs Stufen
- 01 Key-Login einrichten und testen
- 02 Passwort-Login deaktivieren
- 03 root-Login sperren, AllowGroups setzen
- 04 Ciphers und Forwarding begrenzen
- 05 nftables und Fail2Ban davorschalten
- 06 Logging und Zwei-Faktor ergänzen
Die sshd_config Schritt für Schritt härten
Die folgenden Punkte bilden die Reihenfolge ab, in der du vorgehen solltest. Jede Änderung prüfst du mit sshd -t auf Syntaxfehler und testest sie in einer zweiten, parallel geöffneten Session, bevor du die erste schließt.
Key-Authentifizierung sauber aufsetzen
Erzeuge Schlüssel mit ssh-keygen -t ed25519 und vergib eine Passphrase, die der Agent im Alltag puffert. Verteile den Public Key mit ssh-copy-id und prüfe, dass der Login ohne Passwort funktioniert. Erst danach setzt du PasswordAuthentication no, KbdInteractiveAuthentication no und PubkeyAuthentication yes.
root-Login und Benutzerkreis eingrenzen
PermitRootLogin no ist der Regelfall, prohibit-password bleibt nur dann vertretbar, wenn Automatisierung wirklich als root anmelden muss. Über AllowGroups ssh-users gibst du den Zugang explizit frei, statt einzelne Konten nachträglich zu sperren. Das ist robuster, weil neue Systemkonten dann nicht versehentlich Zugriff erben.
Kryptografie auf aktuelle Verfahren beschränken
Beschränke KexAlgorithms, Ciphers und MACs auf moderne Verfahren, also etwa curve25519-sha256, chacha20-poly1305 oder aes256-gcm und ausschließlich Encrypt-then-MAC-Varianten. Prüfe vorher, welche Clients und welche alten Systeme sich verbinden müssen, sonst sperrst du Backup- oder Monitoring-Jobs aus.
Angriffsfläche des Dienstes reduzieren
Setze MaxAuthTries auf einen niedrigen Wert, begrenze LoginGraceTime, deaktiviere AllowTcpForwarding, AllowAgentForwarding und X11Forwarding, wenn sie nicht gebraucht werden, und binde den Dienst über ListenAddress an das Interface, das ihn wirklich anbieten soll. Für einzelne Konten steuerst du Abweichungen über Match-Blöcke am Dateiende.
Brute-Force-Schutz und Netzwerkfilter kombinieren
Fail2Ban oder CrowdSec sperren auffällige Quell-IPs zeitlich befristet. Wirksamer ist eine Filterregel in nftables, die SSH nur aus dem Management-Netz oder vom VPN aus erlaubt. Beides ergänzt sich, ersetzt sich aber nicht.
Zwei-Faktor und Zugriffe nachvollziehbar machen
Für Sprungserver lässt sich ein zweiter Faktor per PAM-Modul oder über zertifikatsbasierte Schlüssel mit kurzer Gültigkeit ergänzen. Setze LogLevel VERBOSE, damit der Fingerprint des verwendeten Schlüssels im Journal landet, und werte die Anmeldungen zentral aus.
Kurse zu SSH-Härtung bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu SSH-Härtung
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktBringt es etwas, den SSH-Port von 22 auf einen anderen Port zu legen?
Wie deaktiviere ich den Passwort-Login, ohne mich auszusperren?
Ed25519 oder RSA für SSH-Schlüssel?
Reicht Fail2Ban als Schutz für SSH aus?
Wo gehören eigene Einstellungen hin, in die sshd_config oder in ein Drop-in?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
SSH-Härtung im Kurs am eigenen System durchspielen
Wenn du Härtung nicht nur nachlesen, sondern an laufenden Systemen üben willst, passt der Linux Security Intensivkurs. Dort gehst du sshd_config, PAM, Paketfilter und Angriffserkennung im Zusammenhang durch. Wer den Fernzugriff im Netzkontext betrachten möchte, findet im Kompaktkurs Linux Netzwerk und Netzwerkdienste den passenden Rahmen. Beide Kurse gibt es als Präsenz- und als Live-Online-Termin, und wenn du unsicher bist, welcher zu deinem Setup passt, melde dich einfach bei uns.