SSH-Sicherheit auf Linux-Servern: Von Basics bis Härtung

Jeder Linux-Server, der öffentlich erreichbar ist, wird innerhalb weniger Minuten von automatisierten Bots angegriffen. Wer das nicht glaubt, schaut einfach in /var/log/auth.log – dort finden sich oft Tausende fehlgeschlagener Login-Versuche pro Tag. SSH ist das wichtigste Einfallstor, und entsprechend sollte es behandelt werden.

In diesem Artikel gehe ich durch alle relevanten Härtungsmaßnahmen – von den absoluten Grundlagen bis hin zu fortgeschrittenen Techniken wie MFA und Zertifikats-basierter Authentifizierung. Das Ziel: ein SSH-Zugang, der wirklich sicher ist, ohne dabei unpraktisch zu werden.

Warum Standard-SSH gefährlich ist

Nach der frischen Installation eines Ubuntu- oder Debian-Servers ist SSH meist schon aktiv – und mit Standardeinstellungen, die für Produktivsysteme nicht geeignet sind:

• Root-Login per Passwort ist erlaubt
• SSH lauscht auf dem bekannten Port 22
• Passwort-Authentifizierung ist aktiv
• Es gibt keine Ratenbegrenzung für Login-Versuche
• Ältere, unsichere Cipher-Suites sind oft noch aktiv

Die Angriffsfläche ist damit maximal. Bots scannen kontinuierlich das Internet nach Port 22, probieren schwache Passwörter durch (Brute-Force) und nutzen bekannte Default-Credentials. Das ist kein hypothetisches Risiko – es passiert rund um die Uhr.

Schritt 1: SSH-Schlüssel statt Passwort

Die wichtigste Einzelmaßnahme ist die Umstellung auf Public-Key-Authentifizierung. SSH-Keys sind kryptografisch stark und können nicht durch Brute-Force geknackt werden. Der Ablauf ist einfach:

Key-Paar lokal erzeugen

# Ed25519 ist aktuell der empfohlene Typ (sicherer und schneller als RSA)
ssh-keygen -t ed25519 -C "emre@server-prod-01" -f ~/.ssh/id_ed25519_prod

# Optional: RSA mit 4096 Bit (für ältere Kompatibilität)
ssh-keygen -t rsa -b 4096 -C "emre@server-prod-01" -f ~/.ssh/id_rsa_prod

Public Key auf den Server übertragen

# Einfachste Methode
ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub user@server-ip

# Alternativ manuell
cat ~/.ssh/id_ed25519_prod.pub | ssh user@server-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Nachdem du den Key-Login getestet hast, deaktivierst du die Passwort-Authentifizierung in /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

Schritt 2: Root-Login deaktivieren

Root ist das erste Konto, das Angreifer probieren. Kein direkter Root-Login über SSH – das ist eine der einfachsten und wirkungsvollsten Maßnahmen:

PermitRootLogin no

Stattdessen nutzt du einen normalen Benutzer mit sudo-Rechten. Falls noch kein solcher existiert:

adduser emre
usermod -aG sudo emre

Schritt 3: Kritische sshd_config-Parameter

Eine vollständige, gehärtete /etc/ssh/sshd_config (relevante Parameter):

# Protokoll und Netzwerk
Port 2222                          # Nicht-Standard-Port (kein echtes Security-Feature, aber weniger Rauschen)
AddressFamily inet                 # Nur IPv4 (oder inet6 für nur IPv6)
ListenAddress 0.0.0.0

# Authentifizierung
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no

# Sessions und Timeouts
LoginGraceTime 30                  # 30 Sekunden für Login-Versuch
MaxAuthTries 3                     # Max. 3 Fehlversuche pro Session
MaxSessions 5
ClientAliveInterval 300            # Nach 5 Min. Inaktivität checken
ClientAliveCountMax 2              # 2 Checks, dann trennen

# Einschränkungen
AllowUsers emre deploy             # Nur diese User dürfen sich einloggen
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no              # Kein Tunnel-Missbrauch
PermitTunnel no
PrintMotd no

# Logging
LogLevel VERBOSE                   # Mehr Details im Auth-Log

# Kryptografie (moderne Standards)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

Nach jeder Änderung: Konfiguration prüfen und neu laden:

# Syntax prüfen (gibt Fehler aus, ohne zu laden)
sshd -t

# Neu laden ohne bestehende Sessions zu trennen
systemctl reload sshd

Schritt 4: Fail2ban installieren und konfigurieren

Fail2ban überwacht Log-Dateien und sperrt IPs automatisch, die zu viele fehlgeschlagene Login-Versuche produzieren. Ein unverzichtbares Tool für jeden öffentlich erreichbaren Server:

apt install fail2ban -y

# Konfiguration via jail.local (überschreibt jail.conf)
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Relevante Einstellungen in /etc/fail2ban/jail.local:

[DEFAULT]
# IP nach 3 Fehlversuchen für 1 Stunde sperren
bantime  = 3600
findtime = 600
maxretry = 3

# Eigene IPs nie sperren
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16

[sshd]
enabled  = true
port     = 2222          # Falls Port geändert wurde
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 86400         # 24 Stunden bei SSH-Angriffen

systemctl enable fail2ban
systemctl start fail2ban

# Status prüfen
fail2ban-client status sshd

# Gebannte IPs anzeigen
fail2ban-client status sshd | grep "Banned IP"

Schritt 5: Firewall – nur SSH-Zugang erlauben

UFW (Uncomplicated Firewall) macht es einfach, den Zugang zu kontrollieren. Grundregel: alles sperren, nur Notwendiges öffnen:

ufw default deny incoming
ufw default allow outgoing

# Falls Port 2222 verwendet wird
ufw allow 2222/tcp comment 'SSH'

# Web-Dienste (falls benötigt)
ufw allow 80/tcp
ufw allow 443/tcp

# Erst aktivieren, wenn SSH-Verbindung korrekt konfiguriert ist!
ufw enable

ufw status verbose

IP-Whitelist für SSH

Wenn du eine feste IP hast (z.B. im Büro oder per VPN), ist eine Whitelist ideal:

# Nur diese IP darf SSH
ufw allow from 203.0.113.42 to any port 2222 proto tcp comment 'SSH nur von Büro-IP'

# Alle anderen blockieren
ufw deny 2222/tcp

Schritt 6: SSH-Zertifikate für Teams (fortgeschritten)

Bei größeren Teams wird die Verwaltung von authorized_keys-Dateien schnell unübersichtlich. SSH Certificate Authority (CA) löst dieses Problem elegant: Du signierst einmalig eine CA, und Benutzer können sich mit von der CA signierten Schlüsseln authentifizieren.

# CA-Key erzeugen (einmalig, sicher aufbewahren!)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "techz-ca"

# Benutzer-Key signieren (Gültigkeit: 7 Tage)
ssh-keygen -s /etc/ssh/ca_key \
  -I "emre@techz" \
  -n emre \
  -V +7d \
  ~/.ssh/id_ed25519.pub

# Server-Konfiguration: CA vertrauen
echo "TrustedUserCAKeys /etc/ssh/ca_key.pub" >> /etc/ssh/sshd_config

Zertifikate haben einen eingebauten Ablaufzeitpunkt – verloren gegangene Keys werden automatisch ungültig. Kein manuelles Entfernen aus authorized_keys auf jedem Server mehr.

Schritt 7: 2FA mit Google Authenticator (optional)

Für besonders kritische Server lohnt sich ein zweiter Faktor per TOTP (Time-based One-Time Password):

apt install libpam-google-authenticator -y

# Für jeden Benutzer einrichten
google-authenticator

In /etc/pam.d/sshd die folgende Zeile einfügen (vor anderen Auth-Regeln):

auth required pam_google_authenticator.so

In sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Mit dieser Konfiguration müssen Benutzer sowohl ihren SSH-Key als auch einen TOTP-Code vorweisen. Selbst ein kompromittierter Private Key reicht dann nicht mehr aus.

Monitoring und Audit-Logs

Sicherheit ohne Monitoring ist blind. SSH-Logins sollten überwacht werden. Ein paar nützliche Befehle:

# Alle SSH-Logins der letzten 24h
journalctl -u sshd --since "24 hours ago" | grep "Accepted"

# Fehlgeschlagene Versuche live beobachten
tail -f /var/log/auth.log | grep "Failed password\|Invalid user"

# Aktive SSH-Sessions
who
ss -tnp | grep ssh

# Letzte Logins
last -n 20

# Verdächtige IPs aus auth.log extrahieren
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Schnell-Checkliste: SSH-Härtung

Eine kompakte Übersicht aller Maßnahmen:

• ✅ SSH-Keys statt Passwörter (PasswordAuthentication no)
• ✅ Root-Login deaktivieren (PermitRootLogin no)
• ✅ AllowUsers auf konkrete Nutzer beschränken
• ✅ LoginGraceTime auf 30s reduzieren
• ✅ MaxAuthTries auf 3 setzen
• ✅ Fail2ban installieren und konfigurieren
• ✅ Firewall (UFW) mit SSH-Whitelist aktivieren
• ✅ Nicht-Standard-Port verwenden (reduziert Log-Rauschen)
• ✅ Moderne Cipher-Suites erzwingen
• ✅ LogLevel VERBOSE für bessere Audit-Trails
• ✅ ClientAliveInterval für automatische Session-Timeouts
• ⭐ SSH-Zertifikate für Teams (skalierbare Verwaltung)
• ⭐ 2FA für hochkritische Systeme

Fazit

SSH absichern ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Die Grundmaßnahmen – Key-Authentifizierung, kein Root-Login, Fail2ban, Firewall – sind in weniger als einer Stunde umgesetzt und reduzieren die Angriffsfläche dramatisch.

Die fortgeschrittenen Techniken wie SSH-Zertifikate oder 2FA lohnen sich besonders in Teams und für Server, auf denen kritische Daten oder Dienste laufen. Der Aufwand ist überschaubar, der Sicherheitsgewinn erheblich.

Wer SSH wirklich ernst nimmt, kombiniert technische Härtung mit regelmäßigem Log-Monitoring. Ein unüberwachter Server ist nie vollständig sicher – egal wie gut er konfiguriert ist.