Ubuntu-Initialisierung: Benutzer, SSH und fail2ban absichern

Um drei Uhr nachts starrte ich auf die Zeile „Permission denied“ im Terminal – mir lief es kalt den Rücken runter.

Kein Zugriff mehr auf den Server. Nur weil ich kurz die SSH-Konfiguration geändert und keinen Notfallzugang offen gelassen hatte.

Das war vor drei Jahren, als ich meinen ersten VPS kaufte. Heute wirkt das wie ein Lehrbuch der Fehler: root-Login, Geburtstags-Passwort, Standard-Port 22, Firewall? Unbekannt. Nach zwei Wochen war der Server voll mit Brute-Force-Spuren in den Logs.

Viele kaufen einen VPS und wollen sofort Software installieren und deployen. Benutzer, SSH-Härtung? „Später.“ Genau diese „später“-Schritte entscheiden, wie lange der Server durchhält.

Dieser Artikel macht eines: Einen frischen Ubuntu-Server (22.04 oder 24.04) von null auf sicher und nutzbar bringen. Benutzerrechte, SSH-Härtung, fail2ban – mit Erklärung des „Warum“, nicht nur Copy-Paste-Befehle.

Etwa zehn Minuten für den kompletten Ablauf. Danach liegt Ihre Absicherung über dem Niveau der meisten „nackten“ VPS im Netz.

1. Vorbereitung vor der Initialisierung

Bevor Sie loslegen: SSH-Schlüssel auf dem lokalen Rechner erzeugen.

Warum Schlüssel statt Passwort? Passwörter lassen sich per Brute Force angreifen, Schlüssel praktisch nicht. Ein 256-Bit-Ed25519-Schlüssel übersteigt jede realistische Knackzeit.

Schlüssel erzeugen

Ed25519 ist heute Standard – sicherer als älteres RSA, kürzere Schlüssel:

# macOS / Linux
ssh-keygen -t ed25519 -C "[email protected]"

# Windows (PowerShell, OpenSSH-Client erforderlich)
ssh-keygen -t ed25519 -C "[email protected]"

Speicherort und optionale Passphrase: Enter für Standardpfad; Passphrase erhöht die Sicherheit, muss aber bei jedem Login eingegeben werden.

Danach lokal zwei Dateien:

• ~/.ssh/id_ed25519 – privater Schlüssel, niemals weitergeben
• ~/.ssh/id_ed25519.pub – öffentlicher Schlüssel für den Server

Terminal: Unter macOS reicht die eingebaute Terminal-App; unter Windows Windows Terminal oder MobaXterm. Details dazu sind Nebensache.

2. Benutzer und Berechtigungen

Zuerst per root einloggen (das letzte Mal direkt als root – danach wird es deaktiviert):

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

ssh root@Ihre-Server-IP

Warum kein root?

Kurz: Die Konsequenzen sind zu groß.

root kann mit einem falschen Befehl das System zerstören. Viele Angriffsskripte zielen gezielt auf root per SSH. root im Login zu belassen, ist ein großes Ziel.

Alltag mit normalem Konto, sudo nur bei Bedarf – Grundprinzip der Linux-Absicherung.

Deployment-Benutzer anlegen

Ich nutze oft deploy („nur für Deployment“). Jeder Name ist möglich:

# Benutzer anlegen (Passwort und Metadaten werden abgefragt)
adduser deploy

# sudo-Rechte
usermod -aG sudo deploy

Passwort merkbar setzen, übrige Felder mit Enter überspringen.

Öffentlichen Schlüssel zum neuen Benutzer

Den lokalen öffentlichen Schlüssel auf den Server bringen – auf dem lokalen Rechner:

# macOS / Linux
ssh-copy-id deploy@Ihre-Server-IP

# Windows (PowerShell)
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@Ihre-Server-IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Login testen:

ssh deploy@Ihre-Server-IP

Funktioniert es? Ab jetzt mit deploy arbeiten, nicht wieder zu root wechseln. Root-Rechte nur über sudo.

Mehrere Benutzer

Für Teams: pro Person ein Konto, z. B.:

# Konto für Kollegin Zhang
adduser zhangsan
usermod -aG sudo zhangsan

# Öffentlichen Schlüssel (lokal von Zhang ausführen)
ssh-copy-id zhangsan@Ihre-Server-IP

Jeder nutzt sein Konto – Nachvollziehbarkeit und Fehlersuche werden einfacher.

3. SSH absichern

Der kritischste Schritt – und die häufigste Quelle für „ausgesperrt“.

Warnung: Vor Änderungen an sshd_config die aktuelle SSH-Session offen lassen und parallel in einem zweiten Terminal testen. Bei Fehlkonfiguration können Sie so noch korrigieren.

SSH-Konfiguration bearbeiten

sudo nano /etc/ssh/sshd_config

Kernparameter im Detail

1. Port

Port 22    # Standard – besser ändern

Port 22 ist das Hauptziel automatisierter Scans. Hoher Port (z. B. 22222 oder 54321) filtert viele Massenscans heraus.

Port 54321

Bei Cloud-Anbietern (Alibaba Cloud, Tencent Cloud, AWS usw.) nach der Änderung den neuen Port in Security Group / Firewall freigeben – sonst keine Verbindung.

2. PermitRootLogin – root verbieten

PermitRootLogin no    # Pflicht

root ist das Lieblingsziel von Angreifern. Deaktivieren schränkt die Angriffsfläche stark ein.

3. PasswordAuthentication – Passwort-Login aus

PasswordAuthentication no    # nur Schlüssel

Schutz vor Passwort-Brute-Force. Ohne Ihren privaten Schlüssel hilft kein Passwort.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

4. Weitere Parameter

MaxAuthTries 3              # maximal 3 Fehlversuche
ClientAliveInterval 300     # nach 5 Min. Inaktivität prüfen
ClientAliveCountMax 2       # maximal 2 Mal ohne Antwort

Begrenzt Leerlauf-Sessions und Brute-Force-Versuche.

Konfiguration in drei Schritten prüfen

Nicht sofort neu starten – zuerst verifizieren:

Schritt 1: Syntax

sudo sshd -t

Keine Ausgabe = Syntax in Ordnung.

Schritt 2: Verbindung im neuen Fenster

Aktuelles Fenster offen lassen, neues Terminal:

ssh -p 54321 deploy@Ihre-Server-IP

Verbindung klappt? Konfiguration wirkt, Sie sind nicht ausgesperrt.

Schritt 3: Dienst neu starten

sudo systemctl restart sshd
# oder
sudo systemctl restart ssh

Danach erneut im neuen Fenster testen. Erst dann ist der Schritt abgeschlossen.

Tipp

Keine Verbindung mehr? Provider-Konsole (VNC), Konfiguration zurücksetzen, Dienst neu starten. Deshalb: vor SSH-Änderungen immer eine Session offen lassen.

4. fail2ban – automatische Sperren

SSH-Härtung schützt vor Passwort-Angriffen. Hartnäckige Versuche? Dafür fail2ban.

Was ist fail2ban? Überwacht Logs und sperrt verdächtige IPs – zu viele Fehlversuche, temporäre Blockade. Einfach, wirksam.

Installation und Start

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

sshd-Jail konfigurieren

fail2ban nutzt „Jails“ pro Dienst. Für SSH existiert standardmäßig sshd.

Lokale Konfiguration anlegen (nicht die Default-Datei überschreiben – Updates würden sie ersetzen):

sudo nano /etc/fail2ban/jail.local

Inhalt:

[sshd]
enabled = true
port = 54321          # Ihr SSH-Port
maxretry = 3          # nach 3 Fehlversuchen sperren
findtime = 600        # innerhalb von 10 Minuten
bantime = 3600        # 1 Stunde Sperre

Parameter:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• maxretry: erlaubte Fehlversuche (Standard oft 5, hier 3)
• findtime: Zeitfenster in Sekunden (600 = 10 Minuten)
• bantime: Sperrdauer in Sekunden (3600 = 1 Stunde; auch 86400 für einen Tag möglich)

Dienst neu starten:

sudo systemctl restart fail2ban

Sperrstatus anzeigen

# alle Jails
sudo fail2ban-client status

# Details sshd
sudo fail2ban-client status sshd

Liste der gesperrten IPs.

IP entsperren

Eigene IP versehentlich gesperrt?

sudo fail2ban-client set sshd unbanip IHRE-IP

Erweitert: eigene Regeln

fail2ban schützt auch Nginx, Apache, MySQL usw. – weitere Jails analog. Hier nur angedeutet.

5. Versionsunterschiede auf einen Blick

Ubuntu 22.04 und 24.04: gleicher Initialisierungsablauf, einige Details unterscheiden sich.

Kernunterschiede

Praktische Auswirkungen

Gut: SSH-Pfade, fail2ban-Installation und Benutzerbefehle sind identisch.

Beachten:

1. OpenSSH 9.x (24.04) – strengere Defaults, ältere Cipher teils deaktiviert. Alte SSH-Clients ggf. aktualisieren.

2. Cloud-Images: Manche 22.04-Images bringen Monitoring-Skripte mit – Konflikte möglich. Offizielles Minimal-Image oder bestehende Dienste vorher prüfen.

3. Upgrade: Vor 22.04 → 24.04 Snapshot erstellen. do-release-upgrade klappt oft, bei Sicherheitskonfiguration lieber vorsichtig.

Welche Version?

• Neues Projekt: 24.04 – längerer Support, neuere Software.
• Altes Projekt: 22.04 bei Abhängigkeit z. B. von Python 3.10.
• Stabilität: 22.04 ist ausgereift.
• Neues ausprobieren: 24.04 mit besserer Hardware-Unterstützung und Performance.

Zusammenfassung

Kern der Initialisierung:

Sicherheits-Trio:

• Normaler Benutzer, root-Login aus
• SSH: anderer Port, kein Passwort, nur Schlüssel
• fail2ban für verdächtige IPs

Prinzipien:

• Vor Konfigurationsänderungen eine SSH-Session offen lassen
• Jeden Schritt prüfen, nicht hastig neu starten
• Privaten Schlüssel niemals preisgeben

Checkliste:

• Login als deploy über neuen SSH-Port
• root-Login nicht möglich
• Passwort-Login deaktiviert
• fail2ban läuft

Das ist nur der erste Schritt – Firewall (UFW), Docker, Anwendungen folgen später.

Probleme beim Nacharbeiten? Gerne in den Kommentaren. Den Fehler um drei Uhr nachts ohne Zugang möchte ich Ihnen ersparen.