0800 71 20000
Kontakt
...
Security & Hardening

SSH absichern: sshd_config, Schlüssel und Fail2ban

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.

5 Kapitel mit allen Befehlen
Passende Kurse ansehen Persönlich beraten lassen
Zwei Security-Fachleute prüfen ein Dashboard im Betriebsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

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 bremst massenhaftes Durchprobieren von Passwörtern, schützt aber 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.

Miniatur-Szene: Serverschrank in einer Schutzhülle, Vorhängeschlösser und ein Schild davor
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Härtung in sechs Stufen

  1. 01 Key-Login einrichten und testen
  2. 02 Passwort-Login deaktivieren
  3. 03 root-Login sperren, AllowGroups setzen
  4. 04 Ciphers und Forwarding begrenzen
  5. 05 nftables und Fail2Ban davorschalten
  6. 06 Logging und Zwei-Faktor ergänzen
Was du mitnimmst

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-nutzer 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 aktuell halten statt festschreiben

Aktuelle OpenSSH-Versionen wählen von sich aus starke Verfahren, seit Version 10.0 für den Schlüsselaustausch sogar das Post-Quanten-Hybridverfahren mlkem768x25519-sha256. Eine eigene Liste für KexAlgorithms, Ciphers und MACs setzt du nur, wenn eine Prüfvorgabe sie verlangt, und dann mit mlkem768x25519-sha256 und sntrup761x25519-sha512 vorn, chacha20-poly1305 und AES-GCM sowie ausschließlich Encrypt-then-MAC-Varianten. Prüfe vorher, welche Clients und 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

Seit OpenSSH 9.8 bremst sshd über PerSourcePenalties auffällige Adressen bereits selbst aus, Fail2Ban oder CrowdSec sperren sie zusätzlich zeitlich befristet in der Firewall. 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 ergänzt du einen zweiten Faktor per FIDO2-Token oder PAM-Modul, kurzlebige SSH-Zertifikate begrenzen zusätzlich, wie lange ein gestohlener Schlüssel nützt. Setze LogLevel VERBOSE, damit der Fingerprint des verwendeten Schlüssels im Journal landet, und werte die Anmeldungen zentral aus.

Tutorial

sshd_config, Zeile für Zeile

Die folgenden Kapitel gehen die Konfiguration in der Reihenfolge durch, in der du sie anfassen solltest: erst der Zugang selbst, dann die Verfahren, dann alles, was den Missbrauch erschwert. Jede Einstellung steht mit Begründung da, weil eine kopierte sshd_config ohne Verständnis genau die Probleme macht, die du vermeiden willst.

01

Die vier Einstellungen, die zählen

Wenn du nur zehn Minuten hast, sind es diese. Sie erledigen den Großteil dessen, was täglich gegen deinen Server läuft.

/etc/ssh/sshd_config.d/10-haertung.conf
# Keine Passwörter mehr
PasswordAuthentication no
# Auch nicht über den Umweg PAM
KbdInteractiveAuthentication no
# root nie direkt
PermitRootLogin no
# Nur Mitglieder dieser Gruppe
AllowGroups ssh-nutzer

Ein Drop-in unter sshd_config.d/ überlebt Paketaktualisierungen ohne Konflikte mit der Hauptdatei. Die niedrige Nummer ist Absicht: sshd nimmt den ersten gefundenen Wert, und Distributionen legen eigene Dateien ab, etwa 50-redhat.conf auf RHEL (setzt unter anderem X11Forwarding yes) oder 50-cloud-init.conf in Cloud-Images. Eine 99--Datei würde gegen beide verlieren.

  • PasswordAuthentication noDamit sind sämtliche Brute-Force-Versuche erledigt, unabhängig davon, wie gut das Passwort war. Voraussetzung: Dein Schlüssel liegt vorher in authorized_keys und du hast die Anmeldung getestet.
  • KbdInteractiveAuthentication noOhne diese Zeile bleibt bei manchen Distributionen ein zweiter Weg zur Passwortabfrage offen, über PAM. Die Abschaltung der ersten Option allein genügt also nicht.
  • PermitRootLogin noroot ist der einzige Kontoname, den jeder Angreifer kennt. Administration läuft über ein persönliches Konto plus sudo, nur so ist im Nachhinein nachvollziehbar, wer was getan hat.
  • AllowGroups statt AllowUsersEine Gruppe pflegst du an einer Stelle, eine Benutzerliste in der Konfiguration jedes Servers. Ab dem zweiten Host ist die Gruppe die einzige Variante, die auf Dauer gepflegt wird.
Sicher übernehmen
sudo groupadd -f ssh-nutzer
sudo usermod -aG ssh-nutzer $USER

sudo sshd -t                    # Syntaxprüfung, IMMER zuerst
sudo systemctl reload ssh       # Debian/Ubuntu
sudo systemctl reload sshd      # RHEL/Rocky/Alma

# In einem NEUEN Terminal testen, altes offen lassen
ssh -v $USER@server

sshd -t fängt genau die Tippfehler ab, die dich sonst aussperren. Ein reload statt restart lässt bestehende Sitzungen am Leben.

02

Schlüssel richtig erzeugen und verwalten

Ein Schlüssel ohne Passphrase auf einem Notebook ist ein Generalschlüssel zu deiner gesamten Serverlandschaft, der beim ersten Gerätediebstahl mitgeht.

Erzeugen und ausrollen
# ed25519: kurz, schnell, nach heutigem Stand sicher
ssh-keygen -t ed25519 -C "vorname.nachname@firma.de"

# Nur wenn Altsysteme im Spiel sind
ssh-keygen -t rsa -b 4096

# Öffentlichen Teil übertragen
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server

# Auf dem Server: Bei zu offenen Rechten ignoriert sshd die authorized_keys
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

Der Agent nimmt dir die wiederholte Eingabe der Passphrase ab: ssh-add -t 8h ~/.ssh/id_ed25519 hält den Schlüssel acht Stunden bereit und vergisst ihn danach.

Ab etwa zwanzig Servern wird das Verteilen einzelner Dateien unzuverlässig: Irgendwo bleibt der Schlüssel einer ausgeschiedenen Person liegen. Zwei Auswege gibt es. Entweder du rollst authorized_keys über die Konfigurationsverwaltung aus, dann ist die Datei auf dem Server ein Ergebnis und keine Handarbeit. Oder du steigst auf SSH-Zertifikate um: Eine zentrale Instanz signiert Nutzerschlüssel mit begrenzter Gültigkeit, die Server vertrauen nur der Signatur. Damit endet ein Zugang automatisch, statt auf Servern zu überdauern.

Serverseitig einer Zertifizierungsstelle vertrauen
# /etc/ssh/sshd_config.d/10-haertung.conf
TrustedUserCAKeys /etc/ssh/ca_user.pub

# Signieren auf der CA, Gültigkeit acht Stunden
# ssh-keygen -s ca_user -I "anna@firma.de" -n anna -V +8h anna.pub

Der große Gewinn ist der Widerruf: Du musst keinen Schlüssel von hundert Servern entfernen, du signierst ihn einfach nicht mehr.

03

Missbrauch erschweren

Diese Einstellungen verhindern keinen gezielten Angriff, senken aber Last, Rauschen und die Wahrscheinlichkeit, dass ein Fehler unbemerkt bleibt.

Ergänzungen
# Nach drei Fehlversuchen ist die Verbindung zu Ende
MaxAuthTries 3
MaxSessions 4
# 30 Sekunden für die Anmeldung, dann Abbruch
LoginGraceTime 30
# Begrenzt gleichzeitige unauthentifizierte Verbindungen
MaxStartups 10:30:60

# Tote Sitzungen erkennen
ClientAliveInterval 300
ClientAliveCountMax 2

X11Forwarding no
AllowAgentForwarding no
# Nur abschalten, wenn niemand Tunnel braucht
AllowTcpForwarding no

AllowTcpForwarding no bricht Port-Weiterleitungen und damit manche Datenbank-Zugriffe über SSH. Prüfe vorher, wer das nutzt.

~/.ssh/config auf dem Arbeitsplatz
Host sprung
  HostName sprung.firma.de
  User anna

Host srv-*
  ProxyJump sprung
  User anna
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

IdentitiesOnly yes verhindert, dass dein Client der Reihe nach alle vorhandenen Schlüssel durchprobiert und dabei in MaxAuthTries läuft.

04

Erreichbarkeit einschränken

Die wirksamste Maßnahme steht nicht in der sshd_config: Ein Dienst, der aus dem Internet gar nicht erreichbar ist, kann nicht angegriffen werden.

Auf ein Verwaltungsnetz begrenzen
# Nur auf der internen Adresse lauschen
# /etc/ssh/sshd_config.d/10-haertung.conf:
#   ListenAddress 10.0.10.21

# Firewall zusätzlich, zweite unabhängige Ebene
sudo firewall-cmd --permanent --new-zone=verwaltung
sudo firewall-cmd --permanent --zone=verwaltung --add-source=10.0.10.0/24
sudo firewall-cmd --permanent --zone=verwaltung --add-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

# Gegenprobe
ss -tulpn | grep :22

Zwei Ebenen, die unabhängig voneinander wirken: Selbst bei fehlerhafter Firewall-Regel ist der Dienst über die falsche Schnittstelle nicht ansprechbar. Auf Ubuntu ab 22.10 lauscht standardmäßig ssh.socket: Eine neue ListenAddress greift dort erst nach sudo systemctl daemon-reload und sudo systemctl restart ssh.socket.

/etc/fail2ban/jail.local, nur für SSH
[sshd]
enabled  = true
# Debian 12 und neuer schreiben ohne rsyslog kein auth.log
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h
banaction = nftables-multiport
# Eigene Verwaltungsnetze nie sperren
ignoreip = 127.0.0.1/8 ::1 10.0.10.0/24

Status mit sudo fail2ban-client status sshd. Seit OpenSSH 9.8 bremst sshd über die standardmäßig aktive Option PerSourcePenalties auffällige Adressen schon selbst, Fail2Ban verlagert die Sperre zusätzlich in die Firewall, bevor sshd überhaupt Last bekommt.

Wo ein Zugriff von außen unvermeidbar ist, gehört ein zweiter Faktor davor. OpenSSH unterstützt seit Version 8.2 Hardware-Token nach FIDO2 direkt über den Schlüsseltyp ed25519-sk. Der private Schlüssel verlässt den Token nie, und ohne Berührung des Sensors passiert nichts. Das ist bequemer als eine Authenticator-App und deutlich schwerer zu stehlen.

FIDO2-Schlüssel
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "token-anna"
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub anna@server

# Serverseitig Nutzerbestätigung erzwingen
# PubkeyAuthOptions verify-required

-O resident legt den Schlüssel auf dem Token ab, sodass du ihn auf einem neuen Rechner mit ssh-keygen -K zurückholst.

05

Prüfen, dass es wirkt

Eine Konfiguration, die du nicht gegengeprüft hast, ist eine Vermutung.

Abnahme
# Welche Werte gelten wirklich? (löst alle Includes auf)
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauth|allowgroups|maxauth|kbdinteractive'

# Passwortanmeldung muss scheitern
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no benutzer@server
# Erwartet: Permission denied (publickey)

# root muss scheitern
ssh root@server

# Wer meldet sich an, wer scheitert?
# Unit heißt ssh (Debian/Ubuntu) oder sshd (RHEL)
sudo journalctl -u ssh -u sshd -S -24h | grep -E 'Accepted|Failed'

sshd -T ist der einzige verlässliche Weg, den effektiven Zustand zu sehen. Eine Einstellung kann in mehreren Dateien stehen, und es gilt der erste Treffer, nicht der letzte.

Passende Kurse

Kurse zu SSH-Härtung bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Du buchst sie in Präsenz oder Live-Online, auf Wunsch kommen sie auch als Inhouse-Schulung zu deinem Team.

Linux Security Intensivkurs 3 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs Linux Netzwerk und Netzwerkdienste - Kompaktkurs 5 Tage Präsenz nächster Termin 07.12.2026 Zum Kurs Linux Netzwerkadministration Advanced Training (NADM) 3 Tage Präsenz nächster Termin 23.11.2026 Zum Kurs Linux Aufbaukurs: Linux im Netz (LPI04) 3 Tage Präsenz nächster Termin 08.02.2027 Garantietermin Zum Kurs SELinux Training: Grundlagen und Administration (SEL1) 2 Tage Präsenz nächster Termin 11.01.2027 Zum Kurs

Weitere Kurse aus diesem Bereich

Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle Linux-Schulungen mit Terminen.

Unverbindlich beraten lassen Alle IT-Security-Kurse ansehen
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest LPI Essentials Quiz Teste dein Wissen zu Linux-Grundlagen mit unserem LPI Essentials Quiz. Finde heraus, welche Schulungen zu dir passen. Quiz starten Wissenstest LPIC-1 Quiz Teste dein Wissen für die LPIC-1 Prüfungen 101 und 102: Shell, Prozesse, Dateisysteme, Netzwerk und Sicherheit. Quiz starten
Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Gut zu wissen

Häufige Fragen zu SSH-Härtung

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt
Bringt es etwas, den SSH-Port von 22 auf einen anderen Port zu legen?
Es reduziert vor allem das Rauschen durch breite Scans und macht deine Logs lesbarer. Als Schutzmaßnahme taugt es kaum, weil ein Portscan den Dienst in Sekunden findet. Nimm es als Komfortmaßnahme mit, verlasse dich aber auf Key-Login, Zugriffsbeschränkung im Netz und Fail2Ban.
Wie deaktiviere ich den Passwort-Login, ohne mich auszusperren?
Lege zuerst deinen Public Key auf dem Server ab und melde dich in einer zweiten Session ohne Passwort an. Danach setzt du PasswordAuthentication no in einer Datei unter /etc/ssh/sshd_config.d/, prüfst die Syntax mit sshd -t und lädst den Dienst neu. Die erste Session bleibt so lange offen, bis eine neue Verbindung nachweislich funktioniert.
Ed25519 oder RSA für SSH-Schlüssel?
Ed25519 ist der Standardfall, weil die Schlüssel kurz sind, die Implementierung wenig Spielraum für Fehler lässt und alle aktuellen OpenSSH-Versionen sie unterstützen. RSA mit mindestens 3072 Bit brauchst du nur noch für alte Gegenstellen oder Hardware, die Ed25519 nicht kennt.
Reicht Fail2Ban als Schutz für SSH aus?
Nein. Fail2Ban erkennt Muster in den Logs und sperrt Quell-IPs nach mehreren Fehlversuchen, hilft also gegen Passwort-Raten. Gegen einen kompromittierten Schlüssel, eine verwundbare Version oder Angriffe aus vielen verteilten Adressen wirkt es nicht. Es ist eine Ergänzung zu Key-Login und Paketfilter, kein Ersatz.
Wo gehören eigene Einstellungen hin, in die sshd_config oder in ein Drop-in?
Aktuelle Distributionen binden am Anfang der sshd_config ein Include für /etc/ssh/sshd_config.d/ ein. Da in OpenSSH der erste gefundene Wert gilt, legst du deine Einstellungen in eine eigene Datei mit niedriger Nummer, etwa 10-haertung.conf. Distributionen und cloud-init legen dort eigene Dateien wie 50-redhat.conf oder 50-cloud-init.conf ab, die sonst zuerst gelesen würden. Mit sshd -T prüfst du, welcher Wert tatsächlich gilt.

Zuletzt geprüft am 05. Oktober 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Security & Hardening Linux-Server härten: SSH, sudo, nftables und SELinux Weiterlesen Security & Hardening SELinux verstehen: Kontexte, Booleans und AVC-Denials Weiterlesen Security & Hardening Der Cyber Resilience Act und deine Open-Source-Komponenten Weiterlesen Security & Hardening nftables, iptables oder firewalld: was heute Standard ist Weiterlesen
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail
Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

0800 71 20000 E-Mail
Nächster Schritt

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.

Beratung anfragen 0800 71 20000