> ## Content Index
> Fetch the complete content index at: https://sakis.tech/llms.txt
> Use this file to discover other available public pages before exploring further.

# SSH absichern auf Debian & Ubuntu: Schritt für Schritt
- URL: https://sakis.tech/ssh-absichern-auf-debian-ubuntu-schritt-fur-schritt/
- Published: 2026-08-28T09:48:50.000Z
- Updated: 2026-08-28T09:48:50.000Z
- Description: Bots hämmern rund um die Uhr auf Port 22 ein. So stellst du auf SSH-Keys um, schaltest Passwort- und Root-Login ab und lässt fail2ban den Rest erledigen — für Debian, Ubuntu und Raspberry Pi.
- Author: Sakis
- Tags: homelab, sicherheit, linux

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](https://sakis.tech/content/images/2026/08/grafik-4.png)

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.

```bash
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](https://sakis.tech/vaultwarden-mit-docker-installieren-dein-eigener-passwort-manager/).

## 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:

```bash
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:

```bash
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:

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

Und trag diese vier Zeilen ein:

```bash
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:

```bash
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.

```bash
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:

```bash
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:

```bash
sudo nano /etc/fail2ban/jail.local
```

Inhalt:

```bash
[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:

```bash
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](https://sakis.tech/uptime-kuma-mit-docker-installieren-schritt-fur-schritt/).

sakis@homelab:\~$ echo "bleib neugierig — und mach backups" 

## Quellen

- [OpenSSH-Manpage: sshd\_config (alle Optionen und Standardwerte)](https://man.openbsd.org/sshd%5Fconfig?ref=sakis.tech)
- [Ubuntu Server-Doku: OpenSSH-Server konfigurieren](https://documentation.ubuntu.com/server/how-to/security/openssh-server/?ref=sakis.tech)
- [Debian-Wiki: SSH absichern](https://wiki.debian.org/SSH?ref=sakis.tech)
- [fail2ban-Wiki: Proper fail2ban configuration](https://github.com/fail2ban/fail2ban/wiki/Proper-fail2ban-configuration?ref=sakis.tech)