SSH-Server absichern: Vom Passwort zum Zertifikat

SSH-Server absichern: Vom Passwort zum Zertifikat

SSH ist das Tor zu deinem Server. Und genau deshalb ist es auch das beliebteste Ziel für Angreifer. In meinem Endlessh-Dashboard sehe ich täglich hunderte Verbindungsversuche auf Port 22 — Bots die rund um die Uhr anklopfen. Mit ein paar gezielten Maßnahmen machst du es ihnen sehr schwer.

In diesem Artikel zeige ich dir acht Maßnahmen — von den absoluten Basics bis zur SSH Certificate Authority. Jede einzelne erhöht die Sicherheit, und zusammen decken sie alle relevanten Angriffsvektoren ab.

DarkWolfCave.de

ℹ️ Hinweis: Die hier gezeigten Konfigurationen sind Empfehlungen aus meiner eigenen Praxis — keine Garantie für vollständige Sicherheit. Jedes Setup ist anders. Teste Änderungen immer zuerst in einer Testumgebung und passe sie an deine Infrastruktur an. SSH-Härtung hat viele Facetten — dieser Artikel zeigt acht davon.

Das Problem: SSH und das Grundrauschen des Internets

Wenn du einen Server im Internet betreibst, kennst du das: Kaum ist Port 22 erreichbar, hämmern Bots aus aller Welt dagegen. Sie probieren root, admin, ubuntu mit tausenden Passwörtern durch. Das ist kein gezielter Angriff auf dich persönlich — das ist das Grundrauschen des Internets. Automatisierte Scanner die 24/7 das gesamte IPv4-Netz abgrasen.

Ein Standard-SSH-Server mit Passwort-Authentifizierung auf Port 22 ist wie eine offene Einladung. Nicht, weil SSH unsicher wäre — das Protokoll selbst ist gut. Aber die Default-Konfiguration ist auf Kompatibilität optimiert, nicht auf Sicherheit.

In meiner Endlessh-Installation sehe ich diese Angriffe live in Grafana. Die meisten kommen aus China, Russland und den USA — Botnetze die systematisch nach schwachen SSH-Konfigurationen suchen. Endlessh hält sie auf Port 22 fest, aber die eigentliche Absicherung passiert in der sshd_config.

1. SSH-Keys statt Passwörter: Der wichtigste Schritt

Der mit Abstand wichtigste Schritt ist der Wechsel von Passwörtern zu SSH-Keys. Ein gutes Passwort hat vielleicht 80 Bit Entropie. Ein Ed25519-Key hat 256 Bit — ein gewaltiger Unterschied.

Ed25519-Key erstellen

# Ed25519-Key erstellen (empfohlen)
ssh-keygen -t ed25519 -C "dein@email.de"

# Falls Ed25519 nicht unterstützt wird (sehr alte Systeme)
ssh-keygen -t rsa -b 4096 -C "dein@email.de"

Ed25519 ist seit OpenSSH 6.5 verfügbar und der empfohlene Standard. Die Keys sind kürzer, schneller und basieren auf der Curve25519-Elliptischen-Kurve — kryptographisch deutlich stärker als RSA.

Public Key auf den Server kopieren

# Der einfachste Weg
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Manuell (falls ssh-copy-id nicht verfügbar)
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Passwort-Authentifizierung deaktivieren

Erst wenn die Key-basierte Anmeldung funktioniert(!), deaktivierst du Passwörter in /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

⚠️ Wichtig: Teste die Key-Verbindung in einer zweiten Terminal-Session, bevor du die Passwort-Authentifizierung deaktivierst. Die erste Session bleibt als Fallback offen. Erst wenn der Key-Login funktioniert, SSH-Dienst neu starten:

sudo systemctl restart sshd

Damit sind Brute-Force-Angriffe auf Passwörter komplett eliminiert. Die Bots in deinem Endlessh-Log können probieren was sie wollen — ohne den privaten Key kommen sie nicht rein.

2. Root-Login deaktivieren

Die Mehrheit aller SSH-Brute-Force-Angriffe zielt auf den root-Account — Honeypot-Analysen zeigen, dass root mit Abstand der am häufigsten attackierte Benutzername ist. Logisch: root existiert auf jedem Linux-System und hat volle Rechte. Ein einziger Schalter eliminiert diesen gesamten Angriffsvektor:

# /etc/ssh/sshd_config
PermitRootLogin no

Stattdessen nutzt du einen normalen User mit sudo-Rechten:

# Neuen User anlegen (falls noch nicht vorhanden)
adduser deploy
usermod -aG sudo deploy

Selbst wenn ein Angreifer irgendwie gültige root-Credentials hätte — SSH lehnt den Login ab, bevor es überhaupt zu einem Authentifizierungsversuch kommt.

3. SSH-Port ändern

Den Standard-Port 22 auf einen hohen Port zu ändern ist Security through Obscurity — und ja, das alleine reicht nicht. Aber es reduziert das Grundrauschen automatisierter Scans um über 95%. Die meisten Bots prüfen nur Port 22 und ziehen weiter.

# /etc/ssh/sshd_config
Port 2222

⚠️ Wichtig: Ändere den Port niemals auf einem Remote-Server ohne vorher sicherzustellen, dass du über den neuen Port eine Verbindung herstellen kannst. Teste immer in einer zweiten Session!

# ufw installieren (auf Ubuntu vorinstalliert, auf Debian nötig)
sudo apt install ufw

# Firewall anpassen BEVOR du den Port wechselst
sudo ufw allow 2222/tcp comment 'SSH'

# Nach dem Wechsel den alten Port schließen
sudo ufw delete allow 22/tcp

# SSH neu starten
sudo systemctl restart sshd

Die Kombination mit Endlessh auf Port 22 ist besonders elegant: Dein echter SSH läuft auf einem anderen Port, während Endlessh die Bots auf Port 22 in die Falle lockt. So bekommst du die Monitoring-Daten und dein SSH ist gleichzeitig unsichtbar.

💡 Tipp: Speichere die neue Port-Konfiguration in deiner SSH-Config unter einem Namen — dann musst du dir den Port nicht merken.

4. SSH-Algorithmen härten

OpenSSH unterstützt aus Kompatibilitätsgründen auch veraltete Algorithmen. Einige davon gelten inzwischen als kryptographisch gebrochen. Mit ein paar Zeilen in der sshd_config beschränkst du die Auswahl auf moderne, sichere Algorithmen:

# /etc/ssh/sshd_config — Nur sichere Algorithmen
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256

Was diese Einstellungen bedeuten

Einstellung	Empfohlene Algorithmen	Warum
KexAlgorithms	sntrup761, curve25519	Post-Quantum-sicher (sntrup761), bewährte Kurve
Ciphers	chacha20-poly1305, aes256-gcm	AEAD-Verschlüsselung, keine CBC-Schwächen
MACs	hmac-sha2-*-etm	Encrypt-then-MAC (ETM) verhindert Padding-Oracle-Angriffe
HostKeyAlgorithms	ed25519, rsa-sha2-*	Moderne Signaturen, kein SHA1

💡 Tipp: Mit sntrup761x25519-sha512 bist du bereits gegen zukünftige Quantencomputer-Angriffe geschützt. Dieser hybride Key-Exchange kombiniert klassische Kryptografie mit einem Post-Quantum-Algorithmus.

SSH-Konfiguration prüfen mit ssh-audit

Das Tool ssh-audit prüft deine SSH-Konfiguration auf Schwachstellen:

# Installation
pip install ssh-audit

# Eigenen Server prüfen
ssh-audit localhost

# Remote-Server prüfen
ssh-audit dein-server.de

ssh-audit zeigt dir genau welche Algorithmen aktiviert sind, welche als unsicher gelten und gibt konkrete Empfehlungen. Ziel ist ein grüner Status ohne Warnungen.

5. SSH-Zugang auf bestimmte User beschränken

Selbst mit deaktivierten Passwörtern und SSH-Keys gibt es einen weiteren Schutzlayer: Eine explizite Whitelist wer sich per SSH verbinden darf.

# /etc/ssh/sshd_config — Nur bestimmte User
AllowUsers deploy admin

# Alternativ: Gruppenbasiert (flexibler)
AllowGroups ssh-users

Bei der gruppenbasierten Variante:

# Gruppe erstellen und User hinzufügen
sudo groupadd ssh-users
sudo usermod -aG ssh-users deploy
sudo usermod -aG ssh-users admin

Selbst wenn ein Angreifer gültige Credentials für einen anderen User hätte — ohne in der Allow-Liste zu stehen, kommt er nicht rein. SSH lehnt die Verbindung ab bevor die Authentifizierung beginnt.

6. Zwei-Faktor-Authentifizierung einrichten

SSH-Key + TOTP (Time-based One-Time Password) = zwei unabhängige Faktoren. Selbst bei einem gestohlenen Key ist ohne den zweiten Faktor kein Zugang möglich.

Google Authenticator PAM-Modul installieren

# Installieren
sudo apt install libpam-google-authenticator

# Als normaler User ausführen (NICHT als root!)
google-authenticator

Das Tool fragt einige Optionen ab — empfohlene Antworten:

Frage	Antwort	Warum
Time-based tokens?	y	TOTP ist sicherer als HOTP
Update .google_authenticator?	y	Config speichern
Disallow multiple uses?	y	Replay-Schutz
Rate limiting?	y	Brute-Force-Schutz auf OTP-Ebene

PAM konfigurieren

Füge am Ende von /etc/pam.d/sshd hinzu:

auth required pam_google_authenticator.so

sshd_config anpassen

# /etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Nach einem systemctl restart sshd wird bei jedem Login erst der SSH-Key geprüft und dann der TOTP-Code abgefragt.

⚠️ Wichtig: Speichere die Notfall-Codes die bei der Einrichtung angezeigt werden! Ohne Zugang zum Authenticator und ohne Notfall-Codes sperrst du dich aus.

7. SSH-Idle-Timeout konfigurieren

Vergessene offene SSH-Sessions sind ein unterschätztes Risiko. Jemand geht in die Mittagspause, lässt das Terminal offen — und ein Vorbeigehender hat vollen Server-Zugang.

# /etc/ssh/sshd_config
ClientAliveInterval 300    # Alle 5 Minuten prüfen
ClientAliveCountMax 2      # Nach 2 fehlgeschlagenen Checks trennen

Mit diesen Werten wird eine inaktive Session nach 10 Minuten getrennt (300 Sekunden × 2 Versuche). Für die meisten Szenarien ein guter Kompromiss — aktives Arbeiten wird nicht gestört, aber vergessene Sessions werden zuverlässig beendet.

Für besonders sensible Umgebungen:

ClientAliveInterval 120    # Alle 2 Minuten
ClientAliveCountMax 1      # Sofort bei Inaktivität trennen → 2 Min Timeout

8. SSH Certificate Authority: Für fortgeschrittene Setups

Bei mehr als einer Handvoll Servern wird die Verwaltung einzelner authorized_keys-Dateien schnell unübersichtlich. Neuer Mitarbeiter? Key auf alle Server kopieren. Mitarbeiter geht? Key von allen Servern entfernen. Bei 20 Servern ein Albtraum.

Eine SSH Certificate Authority (CA) löst dieses Problem elegant:

CA erstellen

# CA-Schlüsselpaar erstellen (einmalig, sicher aufbewahren!)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "SSH CA"

User-Zertifikat ausstellen

# User-Key signieren (gültig für 52 Wochen)
ssh-keygen -s /etc/ssh/ca_key -I "deploy-user" -n deploy -V +52w user_key.pub

Parameter	Bedeutung
-s ca_key	Signieren mit dem CA-Key
-I "deploy-user"	Zertifikats-ID (für Logs)
-n deploy	Erlaubte Usernamen
-V +52w	Gültigkeit: 52 Wochen

Server konfigurieren

Auf jedem Server muss nur die CA vertraut werden:

# CA Public Key auf den Server kopieren
scp /etc/ssh/ca_key.pub server:/etc/ssh/ca_key.pub

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Vorteile:

• Zentrale Verwaltung — Ein CA-Key statt hunderte authorized_keys
• Zeitliche Begrenzung — Zertifikate laufen automatisch ab
• Widerruf — Über eine Revocation-Liste (RevokedKeys)
• Skalierung — Neue Server vertrauen nur der CA, keine Key-Verteilung nötig

💡 Tipp: Für kleinere Setups (1-5 Server) ist die CA überdimensioniert. Ab 5+ Servern oder mehreren Benutzern lohnt sich der initiale Aufwand aber schnell.

Die komplette sshd_config

Hier alle Maßnahmen zusammengefasst als sshd_config-Snippet. Du kannst diese Einstellungen an deine /etc/ssh/sshd_config anhängen:

# === SSH Hardening ===

# 1. Keys statt Passwörter
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# 2. Kein Root-Login
PermitRootLogin no

# 3. Port ändern (optional, wenn Endlessh auf 22 läuft)
# Port 2222

# 4. Nur sichere Algorithmen
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256

# 5. Nur bestimmte User
AllowGroups ssh-users

# 6. 2FA (erfordert PAM-Konfiguration)
# AuthenticationMethods publickey,keyboard-interactive

# 7. Idle-Timeout
ClientAliveInterval 300
ClientAliveCountMax 2

# 8. Weitere Härtung
MaxAuthTries 3
MaxSessions 3
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

Nach jeder Änderung:

# Konfiguration testen (Syntaxfehler finden)
sudo sshd -t

# Wenn kein Fehler: neu starten
sudo systemctl restart sshd

---

SSH ist das Tor zu deinem Server — und mit diesen acht Maßnahmen ist es gut abgesichert. Keine davon ist kompliziert, und jede einzelne erhöht die Sicherheit messbar.

Fang mit den Basics an (Keys, kein Root, Port ändern) und arbeite dich nach oben. Die Algorithmen-Härtung und ssh-audit kosten fünf Minuten und bringen viel. 2FA und SSH-CA sind für sensiblere Setups die Kür.

Und wenn du sehen willst, wie viele Bots trotzdem noch an Port 22 anklopfen — richte Endlessh als SSH Tarpit ein. Die Monitoring-Daten sind aufschlussreich.

Die komplette Artikelserie

Diese sechs Artikel bilden zusammen einen Leitfaden für Linux-Server-Sicherheit:

1. SSH-Server absichern (dieser Artikel) — Die Eingangstür härten
2. Netzwerk-Sicherheit & Firewall — Den Perimeter schützen
3. Linux-Server härten — Die Angriffsfläche minimieren
4. Monitoring & Intrusion Detection — Angriffe erkennen
5. Endlessh SSH Tarpit — Bots aufhalten und beobachten
6. Backup & Defense-in-Depth — Das Sicherheitsnetz und die Gesamtstrategie