So stoppst du SSH-Brute-Force-Angriffe

Prüfen, ob du angegriffen wirst

Der SSH-Daemon protokolliert jeden fehlgeschlagenen Versuch. Zähle die letzten 24 Stunden und sieh dir dann an, welche Adressen die meisten schicken:

sudo journalctl --since "24 hours ago" | grep -cE "Failed password|Invalid user"

sudo journalctl --since "24 hours ago" \
  | grep -E "Failed password|Invalid user" \
  | grep -oE "from [0-9a-fA-F.:]+ port" | awk '{print $2}' \
  | sort | uniq -c | sort -rn | head -20

Hunderte oder Tausende Zeilen am Tag sind für einen Server mit öffentlicher IP normal. Wird das Journal nicht über Neustarts hinweg aufbewahrt, stehen dieselben Zeilen unter Debian und Ubuntu in /var/log/auth.log und in der RHEL-Familie in /var/log/secure.

SSH-Schlüssel einrichten und zuerst testen

Alles Weitere schaltet Passwörter ab, deshalb brauchst du zuerst einen funktionierenden Schlüssel. Erzeuge auf deinem eigenen Rechner einen Schlüssel, kopiere ihn auf den Server und melde dich damit an. Ersetze deploy durch deinen Benutzer und SERVER_IP durch die Adresse des Servers.

ssh-keygen -t ed25519 -C "laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@SERVER_IP
ssh -i ~/.ssh/id_ed25519 deploy@SERVER_IP

Der letzte Befehl muss dich anmelden, ohne nach dem Passwort des Kontos zu fragen (er darf nach der Passphrase des Schlüssels fragen, die auf deinem Rechner bleibt).

Einen sudo-Benutzer anlegen, bevor du root abschaltest

Wenn du dich heute als root anmeldest, lege zuerst einen normalen Benutzer mit sudo-Rechten an und gib ihm dieselben Schlüssel.

sudo adduser deploy
sudo usermod -aG sudo deploy

sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

sudo mkdir -p /home/deploy/.ssh
sudo cp /root/.ssh/authorized_keys /home/deploy/.ssh/
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

sudo restorecon -R /home/deploy/.ssh

Melde dich aus dem zweiten Terminal als neuer Benutzer an und führe sudo -v aus: Es muss das Passwort des Benutzers annehmen. Erst dann geht es weiter.

Passwort-Login und root-Login abschalten

Aktuelle Versionen von Debian, Ubuntu, der RHEL-9-Familie und Fedora lesen zusätzliche Dateien aus /etc/ssh/sshd_config.d/. Prüfe, ob deine das tut:

grep -i '^Include' /etc/ssh/sshd_config

Gibt der Befehl Include /etc/ssh/sshd_config.d/*.conf aus, schreibst du die Einstellungen in eine eigene Datei. SSH übernimmt für jede Einstellung den ersten Wert, den es liest, und die Dateien werden in alphabetischer Reihenfolge gelesen. Das Präfix 00- gewinnt also gegen Dateien wie 50-cloud-init.conf, die auf manchen Cloud-Images Passwörter wieder einschalten.

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 4
LoginGraceTime 30
EOF

Fehlt die Include-Zeile (RHEL 8 und seine Rebuilds), setzt du dieselben sechs Zeilen direkt in /etc/ssh/sshd_config und ersetzt dort die vorhandenen. Teste dann die Konfiguration und sieh dir die Werte an, die SSH tatsächlich verwendet:

sudo sshd -t && echo "config OK"
sudo sshd -T | grep -Ei '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|maxauthtries) '

Jede Zeile muss den Wert zeigen, den du gesetzt hast. Muss sich root weiterhin mit einem Schlüssel anmelden, etwa für einen Backup-Job, nimm PermitRootLogin prohibit-password statt no. Lade SSH neu: Offene Sitzungen bleiben verbunden.

sudo systemctl reload ssh

sudo systemctl reload sshd

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password deploy@SERVER_IP

Den SSH-Port ändern und wissen, was das nicht bringt

Ein anderer SSH-Port als 22 verringert das Rauschen in den Logs, weil die meisten Bots nur 22 probieren. Sicherer wird SSH dadurch nicht: Portscanner finden einen neuen Port innerhalb von Stunden, ein gezielter Angreifer sofort. Mit reinem Schlüssel-Login spielt der Port kaum eine Rolle. Mach es für sauberere Logs, nicht für die Sicherheit, und erst nach den Schritten oben.

Wähle einen Port (hier 2222), öffne ihn in der Firewall und teile in der RHEL-Familie SELinux mit, dass SSH ihn nutzen darf:

sudo ufw allow 2222/tcp

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Öffne den Port auch in der Cloud-Firewall oder Security Group deines Providers. Setze dann den Port und starte SSH neu:

echo "Port 2222" | sudo tee /etc/ssh/sshd_config.d/01-port.conf
sudo sshd -t && echo "config OK"

Ab Ubuntu 24.04 kann SSH über ssh.socket gestartet werden: Gibt der erste Befehl unten active aus, führe alle vier Zeilen aus, sonst nur die letzte.

systemctl is-active ssh.socket
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl restart ssh

sudo systemctl restart sshd

ssh -p 2222 deploy@SERVER_IP

Hartnäckige Angreifer mit fail2ban oder sshguard sperren

Ohne Passwörter können die Rateversuche nicht mehr gelingen, aber wenn du die Adressen sperrst, die es immer weiter versuchen, sinken Last und Rauschen. fail2ban liest das Log und sperrt eine Adresse nach einer bestimmten Zahl von Fehlversuchen an der Firewall.

sudo apt update
sudo apt install -y fail2ban python3-systemd

sudo dnf install -y epel-release
sudo dnf install -y fail2ban

Unter RHEL selbst und Oracle Linux aktivierst du EPEL so, wie es deren Dokumentation beschreibt, und installierst dann fail2ban. Unter Fedora liegt es in den Hauptrepositorys. Amazon Linux 2023 kann EPEL nicht nutzen: Nimm dort stattdessen das Firewall-Limit unten.

Einstellungen gehören in jail.local, nie in jail.conf, das bei Updates überschrieben wird. Prüfe, ob du schon eine hast, und lege sie dann an. Ersetze YOUR_OFFICE_IP durch die festen Adressen, von denen aus du arbeitest, oder lösch den Eintrag, und setze port auf deinen SSH-Port, falls du ihn geändert hast.

ls -l /etc/fail2ban/jail.local

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 YOUR_OFFICE_IP
bantime = 1h
bantime.increment = true
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd
port = ssh
EOF

Damit wird eine Adresse nach 5 Fehlversuchen in 10 Minuten für eine Stunde gesperrt, und bei jeder Wiederkehr länger. backend = systemd liest das Journal und funktioniert damit auch unter Debian 12 und neuer, wo es /var/log/auth.log eventuell nicht gibt.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Bei einem Angriff steigen Total failed und Currently banned innerhalb weniger Minuten. Bleibt Total failed bei 0, während das Journal fehlgeschlagene Logins zeigt, liest das Jail nicht das richtige Log. So hebst du eine Sperre auf:

sudo fail2ban-client set sshd unbanip 203.0.113.7

sshguard, die schlankere Alternative

sshguard erledigt dieselbe Aufgabe mit weniger Konfiguration und ist für Debian und Ubuntu paketiert (und in EPEL). Trag zuerst deine eigenen Adressen in die Whitelist ein und beobachte dann bei einem Angriff mit sudo journalctl -u sshguard -f die Sperren. Nutze eines der beiden, nicht beide.

sudo apt install -y sshguard
echo "YOUR_OFFICE_IP" | sudo tee -a /etc/sshguard/whitelist
sudo systemctl restart sshguard

SSH an der Firewall begrenzen oder einschränken

Unter Ubuntu und Debian mit ufw weist limit eine Adresse ab, die 6 oder mehr Verbindungen in 30 Sekunden öffnet. Es ersetzt eine einfache allow 22/tcp-Regel. Zeigt sudo ufw status zusätzlich eine OpenSSH-Regel, lösch sie, sobald das Limit aktiv ist (sudo ufw delete allow OpenSSH), denn sie würde vor dem Limit greifen.

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Die Rich Rules von firewalld kennen ein limit, aber es zählt alle Quellen zusammen: Ein Angriff kann das Kontingent aufbrauchen und dich mit aussperren. Für Limits pro Adresse nimmst du in der RHEL-Familie fail2ban.

SSH nur von deinen Adressen erlauben

Der wirksamste Schritt, wenn du von festen Adressen oder über ein VPN arbeitest: Niemand sonst erreicht SSH überhaupt.

sudo ufw allow from YOUR_OFFICE_IP to any port 22 proto tcp
sudo ufw delete limit 22/tcp
sudo ufw status numbered

sudo firewall-cmd --permanent --zone=trusted --add-source=YOUR_OFFICE_IP
sudo firewall-cmd --reload
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --reload

Fragen

Reicht es, den SSH-Port zu ändern, um Brute Force zu stoppen?

Nein. Es senkt die Zahl der Versuche in den Logs, weil die meisten Bots nur Port 22 probieren, aber Scanner finden den neuen Port schnell. Erst der reine Schlüssel-Login macht die Rateversuche nutzlos.

Soll ich fail2ban oder sshguard nehmen?

Für SSH funktionieren beide. fail2ban hat mehr Filter für andere Dienste und mehr Optionen, sshguard braucht weniger Konfiguration. Nutze eines, nicht beide, damit sie sich nicht um dieselben Adressen streiten.

Ich habe Passwörter abgeschaltet und sehe trotzdem fehlgeschlagene Logins. Stimmt etwas nicht?

Nein, alles in Ordnung. Bots versuchen es weiter, weil sie nicht wissen, dass Passwörter abgeschaltet sind. Die Versuche scheitern, bevor überhaupt ein Passwort geprüft wird. Sperren und Verbindungslimits verringern das Rauschen.