# SSH Hardening: Den Zugang zum Herzstück absichern

TL;DR / Management Summary SSH (Secure Shell) ist das wichtigste Werkzeug für Admins – und das beliebteste Ziel für Brute-Force-Angriffe. Eine Standard-Installation ist ein Sicherheitsrisiko. Die drei goldenen Regeln: 1. Deaktivieren Sie Passwort-Authentifizierung (nur Keys!), 2. Verbieten Sie Root-Logins, 3. Nutzen Sie eine 2-Faktor-Authentifizierung oder IP-Whitelisting. Wer diese Schritte umsetzt, reduziert sein Angriffsrisiko um über 90%.

# 1. Einführung & Architektur

Wie sicher ist SSH?

SSH bietet Verschlüsselung und Integrität. Die Schwachstelle ist meist nicht das Protokoll, sondern die Fehlkonfiguration oder schwache Passwörter.

graph LR
    A[Internet / Attacker] --> B{Firewall / UFW}
    B -->|Port 22/2222| C[sshd Daemon]
    C --> D{Check Auth Method}
    D -->|Password| E[High Risk: Brute Force]
    D -->|SSH Key| F[Secure: Cryptographic Proof]
    F --> G[Access Granted]

# 2. Die perfekte sshd_config

Härten der Konfiguration.

Datei: /etc/ssh/sshd_config

# Die wichtigsten Parameter (Enterprise Standard)

# Port ändern (Security through Obscurity, reduziert Log-Spam)
Port 2222

# Protokoll-Version (Immer 2)
Protocol 2

# Login-Einschränkungen
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2

# Authentifizierung
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

# Sicherheitseinstellungen
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

# 3. SSH-Keys: Der einzige sichere Weg

Weg von Passwörtern.

Nutzen Sie moderne Algorithmen wie Ed25519 statt altem RSA.

# Key generieren (auf Ihrem Client)
ssh-keygen -t ed25519 -C "admin@company.com"

# Key auf den Server kopieren
ssh-copy-id -p 2222 user@server-ip

# 4. Day-2 Operations: Banner & Banner-Management

Rechtliche Hinweise und Abschreckung.

Ein Security-Banner schreckt keine Profis ab, ist aber in vielen Compliance-Richtlinien (z.B. ISO 27001) vorgeschrieben.

Datei: /etc/issue.net

***************************************************************************
*                            LEGAL NOTICE                                 *
* This system is restricted to authorized users only. All activities are  *
* logged and monitored. If you are not authorized, disconnect now!        *
***************************************************************************

Aktivierung in sshd_config: Banner /etc/issue.net.

# 5. Troubleshooting & “War Stories”

Wenn man sich selbst aussperrt.

# Story 1: “Der Key-Lockout”

Symptom: Passwort-Auth wurde abgeschaltet, der lokale SSH-Key wurde gelöscht oder der Admin hat keinen Zugriff mehr auf seinen Laptop. Ursache: Keine Out-of-Band Management Strategie. Lösung: Nutzen Sie die Proxmox Web-Konsole oder IPMI, um sich lokal einzuloggen und die sshd_config temporär wieder zu öffnen. Lektion: Hinterlegen Sie immer einen “Emergency Key” in einem physischen Safe.

# Story 2: “DNS-Hänger bei SSH-Login”

Symptom: Der Login-Prozess dauert 30-60 Sekunden, danach geht es blitzschnell. Ursache: sshd versucht einen Reverse-DNS-Lookup der Client-IP, der in einen Timeout läuft. Lösung: Setzen Sie UseDNS no in der sshd_config. Es hat keinen Sicherheitsgewinn und verursacht nur Probleme.

# 6. Monitoring & Intrusion Prevention

Nutzen Sie Fail2Ban, um IPs automatisch zu blockieren, die mehrfach falsche Logins versuchen (siehe Artikel 028).

# Überwachung der SSH-Logins
journalctl -u ssh -f
# Suche nach fehlgeschlagenen Versuchen
grep "Failed password" /var/log/auth.log

# 7. Fazit & Empfehlung

• Key-Only: Passwörter haben auf Servern nichts verloren.
• Port: Das Ändern des Ports (z.B. auf 2222) verhindert 99% des automatisierten Bot-Traffics.
• MFA: Für extrem kritische Server nutzen Sie Google Authenticator (TOTP) als zweiten Faktor für SSH.

# Anhang: Cheatsheet