SSH-Zugang auf dem vServer absichernSchlüssel statt Passwort, Fail2ban und Firewall

Warum das wirklich nötig ist

Wer nach der Bereitstellung eines neuen Servers in die Logdatei /var/log/auth.log schaut, sieht meist schon nach wenigen Stunden Hunderte fehlgeschlagene Anmeldeversuche. Dahinter stecken keine gezielten Angriffe auf dich, sondern Bots, die kontinuierlich das gesamte IPv4-Netz abklappern und Standard-Zugangsdaten durchprobieren: root mit 123456, admin mit admin und so weiter.

Solange dein Root-Passwort lang und zufällig ist, führt das zu nichts. Trotzdem gilt: Ein Passwort kann erraten, abgetippt, in einem Screenshot sichtbar oder aus einem anderen Dienst geleakt werden. Ein SSH-Schlüssel kann das alles nicht. Die folgenden vier Schritte bauen aufeinander auf.

Schritt 1: SSH-Schlüsselpaar erzeugen

Ein SSH-Schlüsselpaar besteht aus einem privaten Schlüssel, der niemals deinen Rechner verlässt, und einem öffentlichen Schlüssel, den du auf dem Server hinterlegst. Erzeugt wird es auf deinem lokalen Rechner, nicht auf dem Server:

ssh-keygen -t ed25519 -C "mein-notebook"

Den vorgeschlagenen Speicherpfad kannst du mit Enter bestätigen. Bei der Frage nach einer Passphrase solltest du eine vergeben - sie schützt den privaten Schlüssel, falls dein Rechner einmal in falsche Hände gerät. Damit du sie nicht bei jeder Verbindung eintippen musst, übernimmt der SSH-Agent deines Betriebssystems das Zwischenspeichern.

Warum ed25519 und nicht RSA? Ed25519-Schlüssel sind kürzer, schneller und nach heutigem Stand mindestens so sicher wie RSA mit 4096 Bit. Nur bei sehr alten Systemen, die Ed25519 noch nicht unterstützen, ist ssh-keygen -t rsa -b 4096 die Ausweichlösung.

Anschließend überträgst du den öffentlichen Schlüssel auf den Server:

ssh-copy-id deinname@DEINE-SERVER-IP

Der Befehl fragt einmalig nach dem Passwort und legt den Schlüssel dann in ~/.ssh/authorized_keys ab. Steht ssh-copy-id nicht zur Verfügung - unter Windows etwa - geht es auch von Hand:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deinname@DEINE-SERVER-IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Jetzt testen, bevor es weitergeht. Öffne ein neues Terminal und verbinde dich. Kommst du ohne Passwortabfrage durch, funktioniert der Schlüssel.

Schritt 2: Passwort-Anmeldung und Root-Login abschalten

Erst wenn der Schlüssel nachweislich funktioniert, schaltest du die Passwort-Anmeldung ab. Lass dabei unbedingt deine bestehende SSH-Sitzung offen - falls etwas schiefgeht, kannst du sie zum Reparieren nutzen.

Öffne die Konfigurationsdatei:

sudo nano /etc/ssh/sshd_config

Suche und setze die folgenden Werte. Stehen sie mit einer Raute davor da, entferne die Raute:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

Speichern mit Strg+O, schließen mit Strg+X. Danach prüfst du die Konfiguration auf Syntaxfehler und lädst den Dienst neu:

sudo sshd -t
sudo systemctl restart ssh

Der Befehl sshd -t ist die wichtigste Zeile im ganzen Ratgeber: Er meldet Fehler, bevor der Neustart dich aussperrt. Gibt er nichts aus, ist alles in Ordnung.

Öffne nun ein zweites Terminal und verbinde dich erneut. Klappt es, ist der Umbau geglückt. Klappt es nicht, machst du in der noch offenen ersten Sitzung die Änderung rückgängig.

Sollte doch einmal beides fehlschlagen: Über die VNC-Konsole im Webinterface kommst du unabhängig von SSH auf das System und kannst /etc/ssh/sshd_config dort korrigieren.

Schritt 3: Fail2ban gegen Dauerbeschuss

Mit deaktivierter Passwort-Anmeldung sind Brute-Force-Versuche zwar aussichtslos, sie belasten aber weiterhin Logdateien und CPU. Fail2ban liest die Logs mit und sperrt IP-Adressen automatisch aus, die zu oft danebenliegen.

sudo apt install fail2ban -y

Die mitgelieferte Konfiguration wird bei Updates überschrieben, deshalb legst du eine eigene Datei an:

sudo nano /etc/fail2ban/jail.local

Inhalt:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

Das bedeutet: Wer innerhalb von zehn Minuten fünfmal scheitert, ist für eine Stunde gesperrt. Aktivieren und prüfen:

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

Die letzte Zeile zeigt dir, wie viele Adressen aktuell gesperrt sind. Nach ein paar Tagen Laufzeit ist das oft eine überraschend lange Liste.

Schritt 4: Firewall auf das Nötigste beschränken

Die Firewall ist die zweite Verteidigungslinie: Selbst wenn ein Dienst versehentlich auf allen Schnittstellen lauscht, kommt von außen niemand daran. Unter Debian und Ubuntu ist ufw das einfachste Werkzeug.

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Die SSH-Regel muss vor dem Aktivieren gesetzt sein, sonst kappt die Firewall im selben Moment deine eigene Verbindung. Weitere Dienste gibst du danach gezielt frei:

sudo ufw allow 80/tcp      # HTTP
sudo ufw allow 443/tcp     # HTTPS
sudo ufw allow 9987/udp    # TeamSpeak 3
sudo ufw status numbered

Mit sudo ufw delete NUMMER entfernst du eine Regel wieder, die du in der nummerierten Übersicht gefunden hast.

Optional: SSH-Port verlegen

Häufig empfohlen wird, SSH von Port 22 auf einen anderen Port zu legen. Ehrlicherweise ist das keine echte Sicherheitsmaßnahme - ein gezielter Angreifer findet den Port mit einem Scan in Sekunden. Was es aber zuverlässig bringt: Die Masse der automatisierten Scans, die stumpf Port 22 abklappern, geht komplett an dir vorbei. Die Logdateien werden dadurch deutlich übersichtlicher.

Wenn du das möchtest, änderst du in /etc/ssh/sshd_config die Zeile Port 22 auf einen Wert über 1024 und gibst ihn vorher in der Firewall frei:

sudo ufw allow 2222/tcp
sudo sshd -t && sudo systemctl restart ssh

Verbinden musst du dich danach mit ssh -p 2222 deinname@DEINE-SERVER-IP. Vergiss nicht, die alte Regel für Port 22 anschließend zu entfernen.

Kurze Checkliste

• Schlüsselpaar erzeugt, öffentlichen Schlüssel hinterlegt und Login getestet
• PasswordAuthentication no und PermitRootLogin no gesetzt
• sshd -t vor jedem Neustart ausgeführt
• Fail2ban aktiv, Status geprüft
• Firewall aktiv, nur benötigte Ports offen
• Privaten Schlüssel gesichert - geht er verloren, kommst du nur noch über die VNC-Konsole ins System

Häufige Fragen