# SSHD Hardening: Den primären Zugangsweg verriegeln

TL;DR / Management Summary SSH ist das Tor zu Ihrem Server. Eine Standard-Konfiguration ist in einer feindlichen Internet-Umgebung (oder auch im LAN) nicht sicher genug. Wir setzen auf Schlüssel-basierte Authentifizierung, verbieten den direkten Root-Login und schalten veraltete, schwache Verschlüsselungsalgorithmen ab. Wer diese Best Practices in der sshd_config umsetzt, reduziert das Risiko einer erfolgreichen Kompromittierung des Zugangswegs auf nahezu Null.

# 1. Einführung & Architektur

Die erste Verteidigungslinie.

Der SSH-Dämon (sshd) lauscht standardmäßig auf allen Schnittstellen. Er ist das erste Ziel für automatisierte Bot-Angriffe.

# Die Security-Schichten (Mermaid)

graph LR
    A[Attacker: Internet] --> B{Firewall: Port 22/2222}
    B -->|Allowed| C[sshd: Handshake]
    C --> D{Cipher Check: Modern?}
    D -->|Fail| E[Disconnect]
    D -->|Success| F{Auth Check: Key?}
    F -->|Password Attempt| G[Deny]
    F -->|Verified Key| H[Login Granted]

# 2. Die gehärtete sshd_config

Präzision in der Konfiguration.

Datei: /etc/ssh/sshd_config

# 1. Authentifizierung & Zugriff

# Nur Protokoll Version 2 erlauben
Protocol 2

# Root-Login verbieten (Immer!)
PermitRootLogin no

# Passwort-Login deaktivieren (Nur SSH-Keys!)
PasswordAuthentication no
PubkeyAuthentication yes

# Leere Passwörter verbieten
PermitEmptyPasswords no

# Maximale Versuche pro Verbindung
MaxAuthTries 3

# 2. Netzwerk-Beschränkungen

# Port ändern (Reduziert Log-Spam um 99%)
Port 2222

# Timeout für inaktive Sitzungen
ClientAliveInterval 300
ClientAliveCountMax 0

# 3. Kryptografisches Hardening

Schwache Algorithmen eliminieren.

Standardmäßig unterstützen viele SSH-Versionen noch alte Verfahren wie 3DES oder SHA1.

# Moderne Kex-Algorithmen und Ciphers

Integrieren Sie diese Zeilen, um moderne Standards zu erzwingen:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# 4. Day-2 Operations: Banner & Management

Rechtliche Absicherung.

# Der rechtliche Hinweis

Hinterlegen Sie einen Banner in /etc/issue.net, um unbefugte Benutzer zu warnen (wichtig für die Beweiskraft bei Audits).

# In sshd_config
Banner /etc/issue.net

# Konfiguration testen

Prüfen Sie Ihre Config immer auf Syntaxfehler, bevor Sie den Dienst neustarten:

sudo sshd -t

# 5. Troubleshooting & “War Stories”

Wenn der Wächter zu streng ist.

# Story 1: “Der Key-Mismatch nach Update”

Symptom: Ein Admin kann sich nach einem OS-Update (z.B. von SLES 12 auf 15) nicht mehr einloggen, obwohl der Key korrekt ist. Ursache: Die neue SSH-Version hat alte RSA-Keys (SHA1) als unsicher markiert und deaktiviert. Lösung: Generieren Sie moderne Ed25519 Keys (Artikel 027). Als Übergangslösung: PubkeyAcceptedAlgorithms +ssh-rsa in der Config (nicht empfohlen!).

# Story 2: “Das verwaiste Sudoers-Problem”

Symptom: Der Admin hat den SSH-Port auf 2222 geändert, aber nun schlagen automatisierte Backups via rsync fehl. Ursache: Die Skripte versuchen weiterhin Port 22 zu nutzen. Lösung: Passen Sie die ~/.ssh/config des Backup-Users an:

Host production-server
    Port 2222
    User backup-bot

# 6. Fazit & Empfehlung

• Key-Only: Machen Sie keine Kompromisse – deaktivieren Sie Passwörter komplett.
• Root-Login: Nutzen Sie einen Standard-User und sudo. Ein direkter Root-Login ist ein “No-Go”.
• Monitoring: Nutzen Sie Fail2Ban (Artikel 028), um IPs nach 3 Fehlversuchen sofort in der Firewall zu sperren.

# Anhang: Cheatsheet