SSH Hardening: Sichere Fernwartung für Linux-Server

SSH ist das wichtigste Verwaltungsprotokoll für Linux-Server. Jeder Server mit Internetzugang wird innerhalb von Minuten nach Inbetriebnahme von automatisierten Bots gescannt — Brute-Force-Angriffe, Credential Stuffing und gezielte Exploits gegen veraltete SSH-Versionen sind Alltag. Eine Standard-SSH-Konfiguration mit Passwort-Authentifizierung und Root-Login ist dabei so einladend wie eine offene Haustür. SSH-Hardening ist keine optionale Maßnahme, sondern Pflicht für jeden produktiven Server.

SSH-Key-Authentifizierung einrichten

Der erste und wichtigste Schritt: Passwörter durch SSH-Keys ersetzen. Ed25519 ist der aktuelle Standard — schneller, sicherer und mit kürzeren Schlüsseln als RSA:

# Ed25519-Schlüsselpaar generieren
ssh-keygen -t ed25519 -C "admin@example.com"

# Public Key auf den Server übertragen
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com

Nach erfolgreicher Key-Hinterlegung kann die Passwort-Authentifizierung deaktiviert werden. Damit werden Brute-Force-Angriffe auf Passwörter sofort wirkungslos.

sshd_config härten

Die zentrale Konfigurationsdatei /etc/ssh/sshd_config bestimmt das Sicherheitsniveau des SSH-Dienstes. Diese Einstellungen bilden eine solide Basis:

# /etc/ssh/sshd_config

# Nicht-Standard-Port (reduziert automatisierte Scans)
Port 2222

# Nur Protokoll 2
Protocol 2

# Root-Login verbieten
PermitRootLogin no

# Passwort-Authentifizierung deaktivieren
PasswordAuthentication no
ChallengeResponseAuthentication no

# Maximale Anmeldeversuche begrenzen
MaxAuthTries 3
MaxSessions 3

# Zugriff auf bestimmte Benutzer/Gruppen beschränken
AllowUsers deploy admin
AllowGroups ssh-users

# Inaktive Verbindungen trennen
ClientAliveInterval 300
ClientAliveCountMax 2

# Unnötige Features deaktivieren
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no

# Starke Kryptografie erzwingen
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Banner anzeigen
Banner /etc/ssh/banner

Nach jeder Änderung die Konfiguration validieren und den Dienst neu starten:

# Konfiguration prüfen (Syntaxfehler erkennen)
sshd -t

# SSH-Dienst neu starten
systemctl restart sshd

Default vs. gehärtete SSH-Konfiguration

Einstellung	Standard	Gehärtet
Port	22	2222 (oder anderer Non-Standard-Port)
PermitRootLogin	yes	no
PasswordAuthentication	yes	no
MaxAuthTries	6	3
X11Forwarding	yes	no
ClientAliveInterval	0 (deaktiviert)	300
AllowUsers / AllowGroups	Alle	Explizite Whitelist
KexAlgorithms	Alle (inkl. schwacher)	Nur moderne Algorithmen
AllowTcpForwarding	yes	no

fail2ban einrichten

fail2ban überwacht SSH-Logs und sperrt IP-Adressen nach mehreren fehlgeschlagenen Anmeldeversuchen automatisch:

# fail2ban installieren
apt install fail2ban

# Lokale Konfiguration erstellen (wird bei Updates nicht überschrieben)
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Die SSH-Jail konfigurieren:

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

# fail2ban starten und aktivieren
systemctl enable --now fail2ban

# Status prüfen
fail2ban-client status sshd

Als leichtgewichtige Alternative eignet sich sshguard — es erkennt Angriffsmuster automatisch und benötigt weniger Konfiguration als fail2ban.

SSH Jump Hosts und Bastion Server

In professionellen Umgebungen sollten interne Server nicht direkt aus dem Internet erreichbar sein. Ein Jump Host (Bastion Server) dient als einziger Zugangspunkt:

# Direkter Zugriff über Jump Host
ssh -J bastion.example.com user@internal-server

# Dauerhaft in ~/.ssh/config konfigurieren
Host internal-*
    ProxyJump bastion.example.com
    User deploy

Host bastion.example.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Der Vorteil: Nur ein Server muss im Internet exponiert und gehärtet werden. Alle internen Server akzeptieren SSH-Verbindungen ausschließlich vom Bastion Host — die Angriffsfläche wird drastisch reduziert.

SSH-Zertifikate statt authorized_keys

Bei vielen Servern wird die Verteilung von Public Keys unübersichtlich. SSH-Zertifikate lösen das Problem: Eine zentrale Certificate Authority (CA) signiert User-Keys, und die Server vertrauen der CA:

# CA-Schlüssel erstellen (einmalig)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "SSH CA"

# User-Key signieren (gültig für 90 Tage)
ssh-keygen -s /etc/ssh/ca_key -I admin@example.com -n deploy -V +90d user_key.pub

Auf den Servern wird nur die CA hinterlegt:

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

Kein manuelles Verteilen von Keys mehr, zentrale Sperrung möglich, automatische Ablaufzeiten — SSH-Zertifikate sind der skalierbare Ansatz für größere Umgebungen.

Zwei-Faktor-Authentifizierung mit Google Authenticator

Für maximale Sicherheit lässt sich SSH mit TOTP-basierter 2FA kombinieren — Key plus Einmalpasswort:

# PAM-Modul installieren
apt install libpam-google-authenticator

# Als Benutzer einrichten
google-authenticator

PAM und sshd konfigurieren:

# In /etc/pam.d/sshd hinzufügen:
auth required pam_google_authenticator.so

# In /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Nach dem Neustart von sshd benötigt jeder Login sowohl den SSH-Key als auch den aktuellen TOTP-Code aus der Authenticator-App.

SSH mit ssh-audit prüfen

Das Open-Source-Tool ssh-audit analysiert die SSH-Konfiguration und bewertet Algorithmen, Schlüssellängen und bekannte Schwachstellen:

# ssh-audit installieren und ausführen
pip install ssh-audit
ssh-audit server.example.com

ssh-audit zeigt farbcodiert an, welche Algorithmen sicher, veraltet oder unsicher sind. Nach dem Hardening sollte der Scan nur grüne Einträge zeigen. Regelmäßige Scans stellen sicher, dass die Konfiguration nach Updates intakt bleibt.

Port Knocking

Port Knocking versteckt den SSH-Port vollständig hinter der Firewall. Erst eine bestimmte Sequenz von Verbindungsversuchen auf geschlossene Ports öffnet den SSH-Zugang temporär:

# knockd installieren
apt install knockd

# /etc/knockd.conf
[openSSH]
    sequence = 7000,8000,9000
    seq_timeout = 10
    command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
    tcpflags = syn

[closeSSH]
    sequence = 9000,8000,7000
    seq_timeout = 10
    command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 2222 -j ACCEPT
    tcpflags = syn

Port Knocking ist kein Ersatz für echte Authentifizierung, aber eine effektive zusätzliche Hürde gegen Port-Scanner und automatisierte Angriffe.

SSH-Monitoring mit DATAZONE Control

Hardening ist kein einmaliges Projekt — Konfigurationen driften, neue Schwachstellen werden entdeckt, und Angriffsmuster ändern sich. DATAZONE Control überwacht SSH-relevante Parameter kontinuierlich:

• Fehlgeschlagene Login-Versuche in Echtzeit erkennen und alarmieren
• sshd_config-Änderungen tracken — unerwartete Abweichungen vom Soll-Zustand sofort melden
• SSH-Key-Rotation überwachen — ablaufende Zertifikate und Keys rechtzeitig identifizieren
• Offene SSH-Sessions monitoren — ungewöhnliche Verbindungszeiten oder -quellen erkennen

Die Kombination aus gehärteter Konfiguration und laufendem Monitoring schließt die Lücke zwischen einmaliger Einrichtung und dauerhaftem Schutz.

Häufig gestellte Fragen

Reicht ein Portwechsel als Schutz?

Nein. Ein nicht-Standard-Port reduziert automatisierte Scans und Log-Rauschen erheblich, bietet aber keinen echten Schutz. Ein gezielter Angreifer findet offene Ports in Sekunden. Portwechsel ist eine sinnvolle Ergänzung, aber kein Ersatz für Key-Authentifizierung und gehärtete Konfiguration.

Was wenn ich mich aussperre?

Vor jeder Änderung: bestehende SSH-Session offen lassen und in einer zweiten Session testen. Bei Cloud-Servern bietet die Konsole des Providers einen Notfall-Zugang. Konfigurationsänderungen immer zuerst mit sshd -t validieren.

Wie oft sollte ich SSH-Keys rotieren?

Für reguläre SSH-Keys gibt es kein technisches Ablaufdatum — eine jährliche Rotation ist gute Praxis. SSH-Zertifikate sollten mit einer Laufzeit von 90 Tagen ausgestellt werden, um das Risiko kompromittierter Keys zu begrenzen.

---

Sie möchten Ihre Linux-Server professionell absichern? Kontaktieren Sie uns — wir implementieren SSH-Hardening, richten Bastion-Server ein und überwachen Ihre Infrastruktur mit DATAZONE Control.