Linux SSH Server absichern: Schritt-für-Schritt für KMU

Jeder Linux-Server, der mit dem Internet verbunden ist, wird innerhalb von Minuten nach dem Start auf Port 22 angegriffen. Automatisierte Bots scannen rund um die Uhr nach erreichbaren SSH-Diensten und probieren systematisch Standardpasswörter durch. Für KMU, die Linux-Server produktiv einsetzen – ob im eigenen Rechenzentrum, beim Hosting-Anbieter oder in der Cloud – ist SSH absichern keine optionale Maßnahme, sondern Grundvoraussetzung.

Warum SSH der kritischste Angriffspunkt ist

SSH (Secure Shell) ist der Standardweg, um Linux-Server remote zu verwalten. Diese Allgegenwärtigkeit macht SSH zum beliebtesten Ziel von Angreifern. Honeypot-Systeme, die absichtlich exponiert werden, registrieren auf Port 22 innerhalb von 24 Stunden regelmäßig mehrere Tausend Login-Versuche – vollautomatisch, ohne menschliches Zutun.

Die häufigsten Angriffsmethoden:

• Brute-Force: Systematisches Durchprobieren von Benutzername/Passwort-Kombinationen
• Credential Stuffing: Nutzung von Passwortlisten aus bekannten Datenlecks
• Default Credentials: Angriffe auf Standardzugangsdaten aus Cloud-Images und Vorlagen-VMs

Für ostdeutsche KMU, die Linux-Server für Dateiablage, Webhosting, ERP-Systeme oder interne Dienste betreiben, sind diese Angriffe tägliche Realität – unabhängig von der Unternehmensgröße.

SSH absichern: Schritt für Schritt

Alle folgenden Maßnahmen betreffen die Hauptkonfigurationsdatei /etc/ssh/sshd_config. Nach jeder Änderung muss der SSH-Dienst neu geladen werden:

systemctl reload sshd

Wichtig: Testen Sie jede Änderung in einer zweiten, aktiven SSH-Sitzung, bevor Sie sich ausloggen. Ein Konfigurationsfehler kann Sie dauerhaft aussperren.

1. Standard-Port 22 ändern

Port 22 ist das erste Ziel jedes automatisierten Scans. Ein abweichender Port (z.B. 2244 oder ein anderer freier Port über 1024) reduziert den Brute-Force-Lärm in Ihren Logs erheblich:

Port 2244

Vergessen Sie nicht, den neuen Port in der Firewall freizugeben und Port 22 zu schließen:

ufw allow 2244/tcp
ufw delete allow 22/tcp

2. Root-Login deaktivieren

Der Benutzer root existiert auf jedem Linux-System – ein bekanntes Ziel, weil der Benutzername nicht erraten werden muss. Direkter Root-Login per SSH sollte grundsätzlich verboten sein:

PermitRootLogin no

Verwalten Sie den Server über einen regulären Administrationsbenutzer mit sudo-Rechten.

3. SSH-Key-Authentifizierung einrichten

SSH-Keys sind deutlich sicherer als Passwörter. Ein Ed25519-Schlüsselpaar ist mit heutigen Mitteln nicht zu bruteforcen und in Sekunden erzeugt.

Schlüsselpaar auf dem eigenen Rechner (Client) erzeugen:

ssh-keygen -t ed25519 -C "admin@mein-unternehmen.de"

Öffentlichen Schlüssel auf den Server übertragen:

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server-ip

4. Passwort-Authentifizierung deaktivieren

Sobald SSH-Keys eingerichtet und getestet sind, können Passwort-Logins vollständig abgeschaltet werden:

PasswordAuthentication no
ChallengeResponseAuthentication no

Damit werden Passwort-Brute-Force-Angriffe gegen Ihren Server faktisch wirkungslos – es gibt keinen Passwort-Mechanismus mehr, den ein Angreifer ausnutzen könnte.

5. Zugelassene Benutzer einschränken

Mit AllowUsers definieren Sie, welche Konten überhaupt SSH-Zugang erhalten:

AllowUsers adminuser deploy-user

Alle anderen Systemkonten – selbst wenn ein Angreifer das Passwort kennen würde – können sich nicht einloggen.

6. Fail2ban gegen Brute-Force installieren

Fail2ban überwacht SSH-Logfiles und sperrt IP-Adressen nach mehreren Fehlversuchen automatisch auf Firewall-Ebene. Installation unter Debian/Ubuntu:

apt install fail2ban

Konfiguration in /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 2244
maxretry = 3
bantime = 3600
findtime = 600

Nach drei fehlgeschlagenen Login-Versuchen innerhalb von 10 Minuten wird die IP-Adresse eine Stunde gesperrt. Das bremst automatisierte Angriffe effektiv aus.

7. Weitere Härtungsoptionen in sshd_config

Zusätzliche Einstellungen, die den Angriffspfad weiter einschränken:

X11Forwarding no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

Diese Einstellungen begrenzen Authentifizierungsversuche je Verbindung, schließen inaktive Sessions nach 10 Minuten automatisch und deaktivieren X11-Forwarding, das gelegentlich für Exploits genutzt wird.

Überblick: Maßnahmen und Aufwand

Was über SSH-Härtung hinausgeht

SSH absichern ist der wichtigste erste Schritt für jeden Linux-Server – aber kein vollständiges Sicherheitskonzept. Für KMU in Dresden und Sachsen gehört zu einer soliden Linux-Server-Absicherung außerdem:

• Firewall-Konfiguration: Nur tatsächlich benötigte Ports nach außen öffnen (UFW, nftables)
• Automatische Sicherheitsupdates: unattended-upgrades sorgt dafür, dass kritische Patches zeitnah eingespielt werden
• Log-Monitoring: Verdächtige Aktivitäten erkennen, bevor Schaden entsteht – etwa mit Grafana/Loki oder einem zentralen Syslog-Server
• Intrusion Detection: Tools wie AIDE erkennen unerwartete Dateiänderungen auf dem System
• Netzwerksegmentierung: Server in isolierte Netzbereiche einbinden, sodass ein kompromittiertes System nicht das gesamte Netz gefährdet

Ein Server-Sicherheitscheck einmal jährlich – ähnlich dem TÜV – gibt kleinen und mittleren Unternehmen Gewissheit über den Zustand ihrer IT-Infrastruktur.

Sie brauchen Unterstützung in Dresden?

Rexoma IT betreut KMU in Dresden und ganz Sachsen beim sicheren Betrieb von Linux-Servern. Von der initialen SSH-Härtung über Firewall-Konfiguration bis hin zu regelmäßigem Monitoring – wir übernehmen die technische Umsetzung, damit Sie sich auf Ihr Kerngeschäft konzentrieren können. Sprechen Sie uns an – kostenloses Erstgespräch, kein Verkaufsgespräch.

Jetzt Kontakt aufnehmen

FAQ: SSH absichern für KMU

Muss ich wirklich den SSH-Port ändern – bringt das wirklich etwas? Ein anderer Port verhindert keinen gezielten Angriff, aber er eliminiert den automatisierten Massenangriff auf Port 22. Der unmittelbare Effekt: deutlich weniger Log-Einträge und weniger Last durch Fail2ban. Als Maßnahme mit minimalem Aufwand und sofort sichtbarem Effekt lohnt es sich.

Was ist sicherer: RSA-Schlüssel oder Ed25519? Ed25519 gilt heute als bevorzugte Wahl – schnellere Verarbeitung, kürzere Schlüssel, und nach aktuellem Stand der Kryptografieforschung mindestens genauso sicher wie RSA mit 4096 Bit. Neue Server sollten immer Ed25519 verwenden.

Kann ich mehrere SSH-Keys für ein Konto hinterlegen? Ja. Die Datei ~/.ssh/authorized_keys kann beliebig viele öffentliche Schlüssel enthalten – einen pro Zeile. Das ist sinnvoll, wenn mehrere Administratoren Zugriff benötigen, ohne ein gemeinsames Passwort zu teilen.

Was passiert, wenn ich mich mit Fail2ban selbst aussperre? Fail2ban sperrt IPs auf Firewall-Ebene. Wenn Ihre eigene Büro-IP blockiert wurde: Entweder warten Sie bis bantime abläuft, oder Sie legen vorab eine Ausnahme für Ihr internes Netz an (ignoreip = 192.168.1.0/24 in jail.local). Bei Cloud-Servern hilft oft die Web-Konsole des Anbieters als Notfallzugang.

Lohnt sich SSH-Härtung auch für Cloud-Server bei Hetzner, AWS oder Azure? Unbedingt – Cloud-Server sind noch stärker exponiert als On-Premise-Systeme. Zusätzlich zu den beschriebenen Maßnahmen empfehlen wir, SSH-Zugang in Security Groups auf bekannte IP-Bereiche zu beschränken und für Produktivumgebungen SSH-Bastion-Hosts einzusetzen.