SSH-Zugang richtig absichern: Schlüssel statt Passwort, Port ändern, fail2ban einrichten

Kurz gefasst

Schlüssel-Login statt Passwort schließt Brute-Force-Angriffe auf SSH praktisch aus
Root-Login per Passwort gehört komplett deaktiviert – Root meldet sich nur noch mit Schlüssel an
Ein geänderter Port reduziert das Grundrauschen automatisierter Scans, ersetzt aber keine echte Absicherung
fail2ban sperrt IP-Adressen automatisch, sobald zu viele Anmeldeversuche fehlschlagen

Jeder Rootserver mit offenem Port 22 bekommt innerhalb weniger Minuten die ersten Anmeldeversuche – nicht von einem Menschen, sondern von Skripten, die rund um die Uhr IP-Bereiche nach offenen SSH-Ports durchprobieren. Die meisten scheitern am Passwort. Manche nicht, weil das Passwort schwach war, weil es woanders schon einmal geleakt ist, oder weil ein Dienst wie im Fall der Proxmox-VE-Lücke, bei der sich Angreifer ganz ohne Passwort als root anmelden konnten, die Authentifizierung selbst untergräbt. Gegen den zweiten Fall kannst du wenig tun außer patchen – gegen den ersten schon.

Warum Passwort-Login das eigentliche Risiko ist

Ein Passwort ist ein Geheimnis, das du dir merken kannst – und genau das macht es angreifbar. Es lässt sich erraten, per Wörterbuch durchprobieren oder aus einem Leak bei einem ganz anderen Dienst wiederverwenden. Ein SSH-Schlüsselpaar dagegen besteht aus einem öffentlichen Teil, der auf dem Server liegt, und einem privaten Teil, der den Server nie verlässt. Ohne den privaten Schlüssel kommt niemand rein, egal wie viele Versuche er unternimmt.

Der sicherste Anmeldeversuch ist der, der technisch gar nicht erst möglich ist – nicht der, der nach fünf falschen Passwörtern gesperrt wird.

Merkmal	Passwort-Login	Schlüssel-Login
Angreifbar durch Brute-Force	Ja	Praktisch nein
Wiederverwendbar aus anderem Leak	Ja, wenn Passwort mehrfach genutzt	Nein, Schlüssel ist einzigartig
Merkbar für den Nutzer	Ja, das ist das Problem	Nein, muss nicht gemerkt werden
Widerruf bei Verlust	Passwort ändern	Public Key aus authorized_keys entfernen

Schritt für Schritt: SSH-Zugang absichern

Schlüsselpaar erzeugen. Auf deinem eigenen Rechner, nicht auf dem Server. Ed25519 ist der aktuelle Standard – kürzere Schlüssel als RSA, mindestens genauso sicher.
```
ssh-keygen -t ed25519 -C "dein-name@rootserver"
```
Public Key auf den Server übertragen. Solange noch Passwort-Login aktiv ist, geht das mit einem Befehl. Die alte Session lässt du dabei offen.
```
ssh-copy-id -p 22 root@dein-server-ip
```
Login testen, bevor du irgendetwas abschaltest. Öffne ein zweites Terminalfenster und melde dich mit dem neuen Schlüssel an, ohne die erste Verbindung zu schließen.
```
ssh root@dein-server-ip
```
Passwort-Login und Root-Passwort-Login deaktivieren. In /etc/ssh/sshd_config die folgenden Zeilen setzen (oder anpassen) und danach den Dienst neu starten.
```
PasswordAuthentication no
PermitRootLogin prohibit-password

systemctl restart sshd
```
Port ändern. Ebenfalls in /etc/ssh/sshd_config, dann Firewall-Regel anpassen und Dienst neu starten. Ports über 1024 vermeiden Kollisionen mit anderen Standarddiensten.
```
Port 2222

ufw allow 2222/tcp
systemctl restart sshd
```

fail2ban installieren und für SSH aktivieren. Eine eigene jail.local anlegen, damit Updates die Konfiguration nicht überschreiben.

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 1h

systemctl restart fail2ban

Schließe die erste, funktionierende SSH-Session erst, wenn du dich in einem separaten Fenster über den neuen Port und mit dem neuen Schlüssel erfolgreich angemeldet hast. Sonst ist der Server für dich zu, bis du ihn über die Rescue-Konsole wieder öffnest.

Port ändern – sinnvoll oder nur Kosmetik?

Ein anderer Port ist kein Sicherheitsmerkmal im eigentlichen Sinn, sondern reduziert vor allem die Menge an automatisiertem Rauschen in den Logs. Wer gezielt nach deinem Server sucht, findet den offenen Port auch auf 2222 oder 22022 – ein einfacher Portscan dauert Sekunden.

Dafür

Deutlich weniger Log-Einträge von automatisierten Massenscans
fail2ban und andere Auswertungen bleiben übersichtlich
Kein Aufwand nach der einmaligen Einrichtung

Dagegen

Kein Schutz gegen einen gezielten Angriff
Muss bei jeder neuen Firewall-Regel und jedem Client mitgedacht werden
Ersetzt Schlüssel-Login und fail2ban nicht, ergänzt sie nur

Nutzt ihr den Server zu mehreren oder von mehreren Geräten aus, legt für jedes Gerät einen eigenen Schlüssel an. So könnt ihr einen einzelnen Zugang widerrufen, ohne allen anderen ebenfalls einen neuen Schlüssel geben zu müssen.

Prüfen, ob es geklappt hat

Nach der Einrichtung lohnt sich eine kurze Kontrolle, bevor du dich auf die neue Konfiguration verlässt.

Passwort-Login testen: Ein Verbindungsversuch mit falschem oder gar keinem Schlüssel muss abgelehnt werden, nicht nach einem Passwort fragen.
Port prüfen: ssh -p 2222 root@dein-server-ip muss funktionieren, ein Versuch auf Port 22 sollte ins Leere laufen.
fail2ban-Status abfragen: fail2ban-client status sshd zeigt aktive Sperren und die Zahl fehlgeschlagener Versuche.
Log kontrollieren: /var/log/auth.log (bzw. journalctl -u sshd) sollte nach ein paar Tagen deutlich weniger Anmeldeversuche zeigen als vorher.

Wenn dein Server danach über längere Zeit unauffällig läuft, ist das die eigentliche Bestätigung – dafür muss aber jemand hinschauen. Wer das nicht manuell im Log verfolgen will, kann die Erreichbarkeit des Servers über unser Monitoring laufend prüfen lassen.

Die Schritte oben gelten für Linux-Rootserver, wie sie in unserer Rootserver-Übersicht stehen. Betreibst du daneben auch einen Windows-Server per RDP, gilt dort ein ganz eigenes Regelwerk – die Details dazu haben wir in unserem Beitrag zum Absichern eines öffentlich erreichbaren Windows-Servers zusammengefasst.

Häufige Fragen

Muss ich den SSH-Port wirklich ändern, wenn ich schon Schlüssel-Login nutze?

Zwingend nicht. Der Schlüssel-Login schließt den eigentlichen Angriffsweg. Der geänderte Port sorgt nur dafür, dass deine Logs nicht von automatisierten Scans zugemüllt werden – nützlich, aber kein Ersatz für den Schlüssel.

Was mache ich, wenn ich mich aus Versehen ausgesperrt habe?

Über die Rescue- bzw. Notfallkonsole im Kundenbereich kommst du unabhängig von SSH auf den Server und kannst die sshd_config dort korrigieren. Deshalb der Hinweis, die alte Session erst zu schließen, wenn die neue nachweislich funktioniert.

Reicht fail2ban allein, ohne Schlüssel-Login zu deaktivieren?

fail2ban bremst Brute-Force-Versuche, verhindert aber nicht, dass ein einmal erratenes oder geleaktes Passwort funktioniert. Beides zusammen ist deutlich robuster als eins von beiden allein.

Funktioniert das auch bei einem frisch bestellten Rootserver?

Ja, die Schritte lassen sich direkt nach der Erstinstallation durchgehen, bevor der Server produktiv genutzt wird. Details zur Bestellung findest du unter Rootserver bestellen.

Wie lange sperrt fail2ban eine IP-Adresse?

Das legst du selbst in der jail.local fest, zum Beispiel mit bantime = 1h wie im Beispiel oben. Für wiederholte Verstöße lässt sich mit bantime.increment auch eine steigende Sperrzeit konfigurieren.