Sobald ein Gameserver, ein VPS oder irgendeine Linux-Maschine online geht, wird die SSH-Sicherheit zu Ihrer wichtigsten Verteidigungslinie. Denn das Erste, was Angreifer versuchen, ist, Hunderte von Benutzername-Passwort-Kombinationen mit automatisierten Tools an den offenen Port 22 zu schicken. In dieser Anleitung zeige ich Schritt für Schritt, wie Sie die schlüsselbasierte Anmeldung einrichten, die Passwortauthentifizierung vollständig deaktivieren, den Port ändern und Brute-Force-Angriffe mit fail2ban automatisch blockieren — mit echten, funktionierenden Befehlen.
Warum ein Passwort allein nicht ausreicht
Passwörter können erraten und geleakt werden und sind anfällig für Wörterbuchangriffe. Wenn Sie die Serverprotokolle prüfen (sudo journalctl -u ssh oder /var/log/auth.log), sehen Sie Hunderte fehlgeschlagener Anmeldeversuche von IPs, die Sie nicht kennen. Ein SSH-Schlüssel dagegen ist ein praktisch unerratbar asymmetrisches kryptografisches Paar: der private Schlüssel bleibt bei Ihnen, während der öffentliche Schlüssel auf den Server kopiert wird. Der Server lässt nur denjenigen herein, der den passenden privaten Schlüssel besitzt. Richtig eingerichtet verschwindet die Bedrohung durch Passwort-Brute-Force vollständig.
1. Ein SSH-Schlüsselpaar erzeugen
Erstellen Sie auf Ihrem eigenen Rechner (nicht auf dem Server) einen modernen, sicheren ed25519-Schlüssel:
ssh-keygen -t ed25519 -C "aslain@laptop"
Der Befehl fragt nach einem Dateipfad und einer optionalen Passphrase. Die Passphrase verschlüsselt Ihren privaten Schlüssel auf der Festplatte mit einem zusätzlichen Passwort; sie bildet eine zweite Barriere, falls Ihr Laptop gestohlen wird — überspringen Sie sie nicht. Sie erhalten zwei Dateien: den privaten Schlüssel ~/.ssh/id_ed25519 und den öffentlichen Schlüssel ~/.ssh/id_ed25519.pub. Den mit der Endung .pub dürfen Sie weitergeben; den ohne Endung niemals.
2. Den öffentlichen Schlüssel auf den Server kopieren
Die einfachste Methode ist ssh-copy-id. Sie fügt Ihren öffentlichen Schlüssel mit den richtigen Berechtigungen zur Datei ~/.ssh/authorized_keys auf dem Server hinzu:
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server_ip
Wenn ssh-copy-id nicht verfügbar ist, können Sie den Schlüssel manuell hinzufügen. Die Berechtigungen müssen stimmen, sonst ignoriert SSH den Schlüssel:
ssh benutzer@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" < ~/.ssh/id_ed25519.pub
Testen Sie nun in einem neuen Terminal, ob Sie sich ohne Passwort (nur mit der Passphrase) anmelden können:
ssh benutzer@server_ip
Überprüfen Sie dies, ohne Ihre aktuelle Sitzung zu schließen; falls der Schlüssel nicht funktioniert, können Sie den Fehler noch beheben, solange die Passwortanmeldung aktiv ist.
3. Passwort- und Root-Anmeldung deaktivieren
Sobald Sie bestätigt haben, dass die Schlüsselanmeldung funktioniert, deaktivieren Sie die Passwortauthentifizierung. Die Konfiguration liegt in /etc/ssh/sshd_config. Erstellen Sie vor dem Bearbeiten eine Sicherung:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
Suchen Sie diese Zeilen (fügen Sie sie hinzu, falls sie fehlen) und setzen Sie ihre Werte:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password lässt root nur mit einem Schlüssel herein; für mehr Sicherheit setzen Sie es auf no und arbeiten mit einem normalen Benutzer plus sudo. Auf manchen Systemen können diese Einstellungen durch Dateien unter /etc/ssh/sshd_config.d/ überschrieben werden; sehen Sie auch dort nach. Testen Sie die Syntax vor dem Anwenden und starten Sie dann den Dienst neu:
sudo sshd -t
sudo systemctl restart ssh
Auf einigen Distributionen heißt der Dienst sshd (systemctl restart sshd). Öffnen Sie nach dem Neustart eine neue Verbindung, ohne die aktuelle Sitzung zu schließen, und bestätigen Sie die Schlüsselanmeldung erneut.
4. Den Port ändern: weniger Rauschen, keine Lösung
SSH vom Standardport 22 auf einen anderen zu verlegen (z. B. 2222 oder 49222) hält die meisten automatisierten Scan-Bots aus Ihren Protokollen heraus. Das ist eine Maßnahme zur Rauschreduzierung, keine Sicherheitsmaßnahme — der echte Schutz sind Schlüssel und fail2ban. Saubere Protokolle zu behalten, ist dennoch wertvoll:
Port 49222
Wenn auf dem Server eine Firewall (wie UFW) läuft, öffnen Sie den neuen Port vor dem Neustart des Dienstes, sonst sperren Sie sich selbst aus:
sudo ufw allow 49222/tcp
sudo systemctl restart ssh
Beim Verbinden müssen Sie nun den Port angeben: ssh -p 49222 benutzer@server_ip. Um ihn nicht ständig tippen zu müssen, fügen Sie eine Verknüpfung zu Ihrer lokalen ~/.ssh/config-Datei hinzu:
Host meinserver
HostName server_ip
User benutzer
Port 49222
IdentityFile ~/.ssh/id_ed25519
Danach genügt ssh meinserver.
5. Brute-Force-Schutz mit fail2ban automatisieren
Selbst bei deaktivierten Passwörtern versuchen Bots weiterhin, sich zu verbinden. fail2ban überwacht die Protokolle und sperrt über die Firewall vorübergehend jede IP, die innerhalb eines festgelegten Zeitfensters zu viele fehlgeschlagene Versuche unternimmt. Installation unter Debian/Ubuntu:
sudo apt update && sudo apt install fail2ban -y
Konfigurieren Sie nicht direkt in jail.conf; verwenden Sie eine jail.local-Überschreibungsdatei, damit Paketupdates Ihre Einstellungen nicht überschreiben:
sudo nano /etc/fail2ban/jail.local
Definieren Sie darin ein Jail für SSH. Wenn Sie den Port geändert haben, tragen Sie ihn in die Zeile port ein:
[sshd]
enabled = true
port = 49222
maxretry = 4
findtime = 10m
bantime = 1h
Diese Einstellung sperrt eine IP für 1 Stunde nach 4 fehlgeschlagenen Versuchen innerhalb von 10 Minuten. Um Wiederholungstäter länger zu bestrafen, können Sie auch bantime.increment = true hinzufügen. Starten Sie den Dienst und prüfen Sie den Status:
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
Die Ausgabe zeigt die Anzahl und Liste der gesperrten IPs. Wenn Sie versehentlich eine IP sperren (zum Beispiel sich selbst), können Sie sie manuell freigeben:
sudo fail2ban-client set sshd unbanip 203.0.113.10
6. Ein paar zusätzliche Härtungsschritte
- Gegen das eigene Aussperren: halten Sie nach jeder kritischen Änderung immer eine zweite Sitzung offen und testen Sie die neue Verbindung.
- Firewall: öffnen Sie mit UFW nur die notwendigen Ports (
sudo ufw default deny incoming) und schließen Sie alles außer Ihren Gameserver-Ports. - Bleiben Sie aktuell: führen Sie regelmäßig
sudo apt update && sudo apt upgradeaus; SSH-Schwachstellen werden meist auf veralteten Systemen ausgenutzt. - Leerlauf-Timeout: schließen Sie inaktive Sitzungen mit
ClientAliveInterval 300.
Häufige Fragen
Wie komme ich hinein, wenn ich meinen privaten Schlüssel verliere?
Wenn Sie die Passwortanmeldung deaktiviert und Ihren einzigen Schlüssel verloren haben, kommen Sie nicht mehr per SSH hinein. Fügen Sie daher mehrere Schlüssel zu authorized_keys hinzu oder halten Sie den Konsolen-/Wiederherstellungszugang Ihres Anbieters (die Webkonsole im VPS-Panel) bereit. Dort können Sie einen neuen Schlüssel erzeugen und hinzufügen.
Reicht das Ändern des Ports allein als Sicherheit?
Nein. Das Ändern des Ports reduziert nur das Rauschen automatisierter Scans; ein gezielter Angreifer scannt Ihren Port mühelos. Echte Sicherheit kommt vom Deaktivieren der Passwörter und der Nutzung von Schlüsseln, plus einer mehrschichtigen Verteidigung wie fail2ban.
Warum sperrt mich fail2ban gelegentlich?
Das passiert meist durch wiederholte Versuche mit falscher Passphrase, falschem Benutzernamen oder einem alten Schlüssel. Prüfen Sie mit fail2ban-client status sshd und geben Sie sich mit unbanip wieder frei; Sie können auch Ihre eigene statische IP in die Zeile ignoreip eintragen.
Möchten Sie Ihren Server kugelsicher machen? Lassen Sie uns gemeinsam SSH und Firewall Ihres Gameservers, VPS oder Webhostings härten. Kontaktieren Sie mich und wir sichern Ihre Infrastruktur von Anfang bis Ende ab.