Häng einen frischen Server ans Internet und schau nach einer Stunde ins Log: Da klopfen längst die ersten Bots an Port 22 und probieren stur Passwörter durch. Rund um die Uhr, aus aller Welt, vollautomatisch. Die gute Nachricht: Mit einer halben Stunde Arbeit machst du aus deinem SSH-Zugang eine Tür, an der die Herrschaften schlicht abprallen. Genau das bauen wir jetzt — auf Debian, Ubuntu oder dem Raspberry Pi, die Schritte sind überall gleich.

Kurz gesagt: Du erzeugst ein SSH-Schlüsselpaar, hinterlegst den öffentlichen Schlüssel auf dem Server, schaltest Passwort- und Root-Login ab und lässt fail2ban hartnäckige Rateversuche automatisch aussperren. Dauer: rund 30 Minuten. Schwierigkeitsgrad: Einsteiger mit Terminal-Grundkenntnissen.
Schaubild: SSH absichern in 4 Schritten — Schlüssel erzeugen, Schlüssel kopieren, Passwörter aus, fail2ban anheuern
Der ganze Weg auf einen Blick: vier Schritte, dann ist Ruhe im Log.

Was du brauchst

  • Einen Server mit Debian, Ubuntu oder Raspberry Pi OS, auf dem SSH schon läuft — plus einen Benutzer mit sudo-Rechten.
  • Deinen eigenen Rechner. OpenSSH steckt in Linux, macOS und Windows 10/11 ab Werk drin.
  • Rund 30 Minuten Zeit und eine zweite, offene SSH-Sitzung als Sicherheitsnetz. Warum, klären wir gleich.

Schritt 1: SSH-Schlüsselpaar erzeugen

Schlüsselpaar? Der öffentliche Schlüssel ist ein Vorhängeschloss, das du an beliebig viele Türen hängen kannst. Der private Schlüssel ist der einzige Schlüssel, der es öffnet — und der verlässt deinen Rechner nie. Ein Passwort kann man erraten. Diesen Schlüssel nicht.

Wichtig: Dieser Befehl läuft auf deinem Rechner, nicht auf dem Server.

ssh-keygen -t ed25519

Ed25519 ist der moderne Standard, den auch die Ubuntu-Doku empfiehlt: kurze Schlüssel, schnell, sicher. Bei den Fragen kannst du den Speicherort einfach mit Enter bestätigen. Die Passphrase dagegen nicht überspringen — sie ist das Schloss vor deinem Schlüssel, falls dein Laptop mal abhandenkommt. Merken musst du sie dir nicht selbst: Ab in den Passwort-Manager damit, zum Beispiel in dein selbst gehostetes Vaultwarden.

Schritt 2: Schlüssel auf den Server kopieren

Jetzt hängen wir das Vorhängeschloss an die Server-Tür. OpenSSH bringt dafür ein eigenes Werkzeug mit:

ssh-copy-id benutzer@server-ip

Einmal das bisherige Server-Passwort eingeben, fertig — der öffentliche Schlüssel landet auf dem Server in ~/.ssh/authorized_keys. Danach sofort testen:

ssh benutzer@server-ip

Fragt der Server jetzt nach der Passphrase deines Schlüssels statt nach dem Server-Passwort, sitzt alles. Und ganz wichtig: Erst wenn dieser Test klappt, geht's weiter. Im nächsten Schritt drehen wir nämlich den Passwort-Login ab — und ohne funktionierenden Schlüssel wäre das die selbstgebaute Aussperrung.

Schritt 3: Passwort- und Root-Login abschalten

Drop-in-Datei? Statt in der großen Hauptkonfiguration herumzueditieren, legst du eine kleine Zusatzdatei in einen Ordner, den der SSH-Server automatisch mitliest. Vorteil: Deine Änderungen bleiben sauber getrennt und überleben jedes System-Update.

Öffne auf dem Server eine neue Datei:

sudo nano /etc/ssh/sshd_config.d/00-haerten.conf

Und trag diese vier Zeilen ein:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3

Was da passiert: PermitRootLogin no sperrt den Benutzer, den jeder Bot als Erstes probiert. PasswordAuthentication no beendet das Passwort-Raten komplett — ab jetzt kommt nur noch rein, wer deinen Schlüssel hat. KbdInteractiveAuthentication no schließt die Seitentür, über die Passwörter sonst per Abfrage-Dialog doch noch durchrutschen könnten. Und MaxAuthTries 3 drosselt die Anmeldeversuche pro Verbindung von sechs auf drei.

Bevor du den Dienst neu startest, lass den SSH-Server seine Konfiguration selbst prüfen:

sudo sshd -t

Keine Ausgabe heißt: alles gut. Jetzt der Neustart — und hier kommt das Sicherheitsnetz ins Spiel. Lass deine aktuelle SSH-Sitzung offen, die bleibt vom Neustart unberührt. Solltest du dich verkonfiguriert haben, kannst du darin alles zurückdrehen.

sudo systemctl restart ssh

Öffne dann ein zweites Terminal und logg dich frisch ein. Klappt es mit dem Schlüssel? Perfekt. Der große Teil ist geschafft — dein Server nimmt schlicht keine Passwörter mehr an.

Schritt 4: fail2ban gegen Dauerklopfer

Fail2ban? Ein Türsteher mit Gedächtnis. Er liest das Anmelde-Protokoll deines Servers mit, zählt Fehlversuche pro Absender — und wer zu oft falsch klopft, kriegt automatisch Hausverbot: Die IP-Adresse wird für eine Weile komplett gesperrt.

Zugegeben: Passwörter raten läuft ab jetzt sowieso ins Leere. Aber die Bots wissen das nicht und dröhnen munter weiter gegen die Tür. Fail2ban sorgt für Ruhe im Log und bremst auch andere Spielereien aus. Die Installation ist ein Einzeiler:

sudo apt install fail2ban

Die mitgelieferten .conf-Dateien gehören dem Paket und werden bei Updates überschrieben — eigene Einstellungen kommen deshalb in eine .local-Datei, so will es die fail2ban-Doku:

sudo nano /etc/fail2ban/jail.local

Inhalt:

[sshd]
enabled = true
backend = systemd

Die Zeile backend = systemd ist wichtiger, als sie aussieht: Debian 12 und neuere Systeme schreiben Anmeldeversuche nicht mehr in die klassische Datei auth.log, sondern ins systemd-Journal. Ohne diese Zeile starrt fail2ban auf eine Log-Datei, die es gar nicht gibt. Danach neu starten und den Status ansehen:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Mit den Standardwerten gilt: Fünf Fehlversuche innerhalb von zehn Minuten, und die IP ist für zehn Minuten gesperrt. Das klingt mild, reicht aber, um automatisierte Rate-Orgien komplett auszubremsen.

Bot→ rät Passwörter →fail2ban→ nach 5 Fehlversuchen →IP gesperrt

Häufige Stolpersteine

  • Ausgesperrt? Passiert, wenn man Schritt 2 nicht sauber getestet hat. Deshalb: immer eine zweite Sitzung offen halten. Und selbst im schlimmsten Fall kommst du über die „echte" Konsole wieder rein — Monitor und Tastatur am Pi, die Konsole im Proxmox-Webinterface oder die Rettungskonsole deines Hosters.
  • Server fragt trotzdem noch nach Passwörtern: Auf Ubuntu-Cloud-Servern liegt oft eine Datei 50-cloud-init.conf im selben Ordner, die PasswordAuthentication yes setzt. SSH liest die Drop-in-Dateien alphabetisch, und der erste Wert gewinnt — genau darum heißt unsere Datei 00-haerten.conf und sticht sie aus. Kontrolle: sudo sshd -T | grep -i passwordauthentication muss no ausgeben.
  • fail2ban startet nicht (Debian 12): Fast immer das fehlende auth.log. Die Zeile backend = systemd in der jail.local behebt genau das.
  • Windows ohne ssh-copy-id: In der PowerShell fehlt das Werkzeug. Der Umweg funktioniert genauso: type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh benutzer@server-ip "cat >> ~/.ssh/authorized_keys"

Fazit

Vier Schritte, eine halbe Stunde, und dein SSH-Zugang spielt in einer anderen Liga: Statt eines ratbaren Passworts braucht ein Angreifer jetzt deinen privaten Schlüssel samt Passphrase, Root ist als Ziel komplett vom Tisch, und Dauerklopfer sitzen im Zehn-Minuten-Takt vor verschlossener Tür.

Meine Einschätzung: Diese vier Schritte sind gut 95 Prozent der Miete, und sie kosten nichts außer etwas Sorgfalt beim Testen. Den SSH-Port zu verlegen, wie es viele Guides empfehlen, bringt dagegen vor allem ruhigere Logs — Sicherheit gewinnst du damit kaum, ein Portscan findet den Dienst trotzdem. Wenn du noch eine Schippe drauflegen willst: Erreichbarkeit von außen nur per VPN statt offener Portfreigabe, das schlägt jede weitere Einzelmaßnahme.

Wie hältst du es mit deinem Server — bleibt Port 22 offen im Netz, oder darf bei dir grundsätzlich nur rein, wer erst durchs VPN kommt? Und nutzt du fail2ban eher als echten Schutz oder einfach für saubere Logs? Schreib's in die Kommentare.

One more thing … ein abgesicherter Server ist gut, ein überwachter ist besser. Wie du mit Uptime Kuma sofort mitkriegst, wenn einer deiner Dienste schlappmacht, steht in unserer Schritt-für-Schritt-Anleitung.

Quellen