0800 71 20000
Kontakt
...
Security & Hardening

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.

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 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.

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-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.

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/99-haertung.conf
PasswordAuthentication no        # keine Passwörter mehr
KbdInteractiveAuthentication no  # auch nicht über den Umweg
PermitRootLogin no               # root nie direkt
AllowGroups ssh-nutzer           # nur wer hier drin ist

Ein Drop-in unter sshd_config.d/ überlebt Paketaktualisierungen. Die Hauptdatei wird bei Upgrades ersetzt, deine Änderungen dort wären dann weg.

  • 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

# Rechte müssen stimmen, sonst verweigert sshd den Dienst
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/99-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
MaxAuthTries 3          # nach drei Fehlversuchen ist die Verbindung zu Ende
MaxSessions 4
LoginGraceTime 30       # 30 Sekunden für die Anmeldung, dann Abbruch
MaxStartups 10:30:60    # begrenzt gleichzeitige unauthentifizierte Verbindungen

ClientAliveInterval 300 # tote Sitzungen erkennen
ClientAliveCountMax 2

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

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/99-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.

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?
sudo journalctl -u ssh -S -24h | grep -E 'Accepted|Failed'
sudo lastb | head

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. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein 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 21.09.2026 Zum Kurs Linux Netzwerkadministration Advanced Training (NADM) 3 Tage Präsenz nächster Termin 21.09.2026 Zum Kurs Linux Aufbaukurs: Linux im Netz (LPI04) 3 Tage Präsenz nächster Termin 23.11.2026 Zum Kurs SELinux Training: Grundlagen und Administration (SEL1) 2 Tage Präsenz nächster Termin 02.11.2026 Zum Kurs
Unverbindlich beraten lassen Alle IT-Security-Kurse ansehen
Gut zu wissen

Häufige Fragen zu SSH-Härtung

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

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 für eine Option gilt, setzt du deine Einstellungen am besten in einer eigenen Datei in diesem Verzeichnis. So bleiben Paketaktualisierungen konfliktfrei und deine Werte gewinnen zuverlässig.

Zuletzt geprüft am 26. Juli 2026.

Weiterlesen

Verwandte Linux-Themen

Alle Linux-Themen im Überblick
Security & Hardening Linux-Server absichern: die Härtungs-Checkliste für deinen Produktivbetrieb Ansehen Security & Hardening SELinux verstehen statt abschalten: Kontexte, Booleans und Troubleshooting Ansehen Security & Hardening Cyber Resilience Act und Open Source: Was auf dich zukommt, wenn dein Produkt Software enthält Ansehen Security & Hardening nftables, iptables oder firewalld: Welche Linux-Firewall du heute nutzen solltest Ansehen
Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

“
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)“
“
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“
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