10 wesentliche Best Practices zur Härtung Ihres SSH-Servers
Härten Sie Ihren SSH-Server mit sichererer Authentifizierung, Zugriff mit geringsten Privilegien, Firewall-Regeln, Ratenbegrenzung, Updates und Log-Überprüfungen.
10 wesentliche Best Practices zur Härtung Ihres SSH-Servers
Secure Shell (SSH) ist normalerweise die Eingangstür zu Ihrem Server. Wenn diese Tür schwache Passwörter, direkte Root-Logins oder Verkehr aus dem gesamten Internet akzeptiert, werden Angreifer sie schnell finden.
Diese Anleitung gibt Ihnen 10 praktische Schritte zur SSH-Server-Härtung, die Sie auf OpenSSH unter gängigen Linux-Distributionen anwenden können. Halten Sie während der Tests eine aktive Sitzung offen, damit Sie sich wieder einloggen können, falls eine Firewall-Regel oder Konfigurationsänderung neue Logins blockiert.
1. Ändern Sie den Standard-SSH-Port
Der Standard-SSH-Port ist 22. Dieser ist allgemein bekannt und wird ständig von automatisierten Bots gescannt, die nach verwundbaren Servern suchen. Das Ändern des Standard-Ports bietet eine einfache, aber effektive Verschleierungsebene. Obwohl es keine Sicherheitsmaßnahme an sich ist, reduziert es erheblich das Rauschen automatisierter Scans und hilft, viele opportunistische Angriffe zu vermeiden.
Um den Port zu ändern, bearbeiten Sie die Datei sshd_config, die sich normalerweise unter /etc/ssh/sshd_config befindet.
sudo nano /etc/ssh/sshd_config
Suchen Sie die Zeile Port 22 (oder fügen Sie sie hinzu, falls sie nicht existiert) und ändern Sie 22 in eine nicht standardmäßige, nicht zugewiesene Portnummer (z. B. 2222, 49152-65535 sind Benutzer-/dynamische Ports).
#Port 22
Port 2222
Erlauben Sie den neuen Port in Ihrer Firewall, bevor Sie SSH neu starten. Testen Sie dann einen neuen Login auf dem neuen Port, bevor Sie den Zugriff auf Port 22 entfernen.
# Für UFW (Uncomplicated Firewall):
sudo ufw allow 2222/tcp
sudo ufw reload
# Für Firewalld:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo sshd -t
sudo systemctl restart sshd
Tipp: Halten Sie während der Tests immer mindestens eine SSH-Sitzung offen. Wenn Sie ausgesperrt werden, können Sie die Änderungen in der aktiven Sitzung rückgängig machen.
2. Deaktivieren Sie den Root-Login
Ein direkter Root-Login über SSH wird dringend abgeraten. Der Benutzer root hat uneingeschränkte Privilegien, was ihn zu einem Hauptziel für Angreifer macht. Wenn ein Angreifer Root-Zugriff erlangt, hat er die vollständige Kontrolle über Ihr System. Melden Sie sich stattdessen als normaler, unprivilegierter Benutzer an und verwenden Sie dann sudo, um administrative Aufgaben auszuführen.
In sshd_config finden Sie die Direktive PermitRootLogin und setzen Sie sie auf no.
PermitRootLogin no
Speichern und starten Sie den SSH-Dienst neu:
sudo systemctl restart sshd
3. Verwenden Sie schlüsselbasierte Authentifizierung
Passwortbasierte Authentifizierung ist anfällig für Brute-Force-Angriffe und Wörterbuchangriffe, insbesondere wenn Benutzer schwache Passwörter wählen. SSH-Schlüsselbasierte Authentifizierung ist eine weitaus sicherere Alternative. Sie verwendet ein Paar kryptografischer Schlüssel: einen öffentlichen Schlüssel, der auf dem Server gespeichert ist, und einen privaten Schlüssel, der auf Ihrem lokalen Rechner verbleibt. Nur Clients mit dem passenden privaten Schlüssel können sich authentifizieren.
Schritte zur Implementierung der schlüsselbasierten Authentifizierung (kurz):
Generieren Sie ein Schlüsselpaar auf Ihrem lokalen Rechner:
ssh-keygen -t ed25519 -C "[email protected]"ed25519ist ein moderner, sicherer Algorithmus mit fester Schlüssellänge.rsaist ebenfalls üblich; wenn Sie RSA verwenden, generieren Sie einen großen Schlüssel wiessh-keygen -t rsa -b 4096.
Kopieren Sie den öffentlichen Schlüssel auf Ihren Server:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ipAlternativ hängen Sie den Inhalt von
~/.ssh/id_ed25519.pubmanuell an~/.ssh/authorized_keysauf dem Server für den Benutzer an, mit dem Sie sich anmelden möchten.Stellen Sie korrekte Berechtigungen auf dem Server sicher:
~/.ssh-Verzeichnis:700(rwx nur für den Besitzer)~/.ssh/authorized_keys-Datei:600(rw nur für den Besitzer)
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
4. Deaktivieren Sie die Passwortauthentifizierung
Sobald Sie die schlüsselbasierte Authentifizierung für alle erforderlichen Benutzer erfolgreich eingerichtet und getestet haben, sollten Sie die Passwortauthentifizierung vollständig deaktivieren. Dies entfernt das schwächste Glied in der SSH-Sicherheit, indem Brute-Force-Passwortangriffe unmöglich gemacht werden.
Setzen Sie in sshd_config PasswordAuthentication auf no.
PasswordAuthentication no
KbdInteractiveAuthentication no
Auf einigen Distributionen können PAM oder die tastaturinteraktive Authentifizierung weiterhin nach Passwörtern fragen, es sei denn, Sie deaktivieren sie ebenfalls. Testen Sie mit einem neuen Terminal, bevor Sie Ihre bestehende Sitzung schließen.
Speichern und starten Sie den SSH-Dienst neu:
sudo systemctl restart sshd
Warnung: Deaktivieren Sie die Passwortauthentifizierung niemals, bevor Sie überprüft haben, dass die schlüsselbasierte Authentifizierung für alle Benutzer, die Zugriff benötigen, korrekt funktioniert. Andernfalls riskieren Sie, sich selbst vom Server auszusperren.
5. Beschränken Sie den Benutzerzugriff
Standardmäßig kann jedes Benutzerkonto auf dem Server versuchen, sich über SSH anzumelden. Sie können den SSH-Zugriff auf bestimmte Benutzer oder Gruppen beschränken und so die Angriffsfläche minimieren.
Verwenden Sie die Direktiven AllowUsers oder AllowGroups in sshd_config.
Um nur bestimmte Benutzer zuzulassen (z. B. adminuser, devuser):
AllowUsers adminuser devuser
Um nur Mitglieder einer bestimmten Gruppe zuzulassen (z. B. sshusers):
AllowGroups sshusers
Tipp: Es ist im Allgemeinen besser, AllowGroups zu verwenden, wenn Sie mehrere Benutzer haben. Erstellen Sie eine dedizierte Gruppe für den SSH-Zugriff und fügen Sie autorisierte Benutzer hinzu.
sudo groupadd sshusers
sudo usermod -aG sshusers adminuser
sudo usermod -aG sshusers devuser
Nach den Änderungen speichern und SSH neu starten.
6. Verwenden Sie starke Passphrasen für SSH-Schlüssel
Obwohl die schlüsselbasierte Authentifizierung robust ist, ist Ihr privater Schlüssel immer noch ein kritisches Asset. Wenn ein Angreifer Zugriff auf Ihren lokalen Rechner erhält, könnte er Ihren privaten Schlüssel stehlen. Eine starke Passphrase verschlüsselt Ihren privaten Schlüssel und erfordert die Passphrase, um ihn vor der Verwendung zu entsperren. Dies fügt eine weitere Sicherheitsebene hinzu und schützt Ihren Schlüssel, selbst wenn er in falsche Hände gerät.
Wenn Sie Ihren SSH-Schlüssel generieren (wie in Schritt 3), werden Sie nach einer Passphrase gefragt. Wählen Sie eine lange, komplexe und einprägsame Passphrase, die sich von allen anderen von Ihnen verwendeten Passwörtern unterscheidet.
7. Implementieren Sie Verbindungsratenbegrenzung (Fail2Ban)
Selbst mit schlüsselbasierter Authentifizierung ist ein SSH-Server immer noch Verbindungsversuchen ausgesetzt. Tools wie Fail2Ban können SSH-Logs aktiv auf wiederholte fehlgeschlagene Anmeldeversuche von derselben IP-Adresse überwachen und diese IP-Adresse automatisch für einen bestimmten Zeitraum mit Firewall-Regeln blockieren.
Installation (Beispiel für Debian/Ubuntu):
sudo apt update
sudo apt install fail2ban
Fail2Ban funktioniert standardmäßig mit den SSH-Standardregeln, aber Sie können die Konfiguration anpassen, indem Sie jail.conf in jail.local kopieren und bearbeiten.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
In jail.local können Sie bantime, findtime und maxretry für den Abschnitt [sshd] anpassen.
[sshd]
enabled = true
port = 2222 # Ihr neuer SSH-Port
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h
findtime = 10m
Starten Sie Fail2Ban nach Konfigurationsänderungen neu:
sudo systemctl restart fail2ban
8. Halten Sie Ihre SSH-Server-Software auf dem neuesten Stand
Software-Sicherheitslücken werden ständig entdeckt und gepatcht. Die Verwendung veralteter SSH-Daemon-Software (OpenSSH) bedeutet, dass Sie möglicherweise bekannten Exploits ausgesetzt sind. Regelmäßige Updates Ihrer Serversoftware, einschließlich des OpenSSH-Serverpakets, sind entscheidend, um Sicherheitslücken zu schließen.
# Für Debian/Ubuntu:
sudo apt update && sudo apt upgrade
# Für CentOS/RHEL:
sudo yum update
# oder
sudo dnf update
Konfigurieren Sie Ihr System so, dass Sicherheitsupdates automatisch angewendet werden, wo dies angemessen ist, oder richten Sie einen regelmäßigen manuellen Update-Prozess ein.
9. Überwachen Sie SSH-Logs auf verdächtige Aktivitäten
Selbst mit robusten vorbeugenden Maßnahmen ist Wachsamkeit der Schlüssel. Überprüfen Sie regelmäßig die SSH-Authentifizierungslogs, um ungewöhnliche Muster, fehlgeschlagene Anmeldeversuche oder unbefugte Zugriffsversuche zu erkennen. Dies hilft Ihnen, potenzielle Einbrüche oder laufende Angriffe zu identifizieren.
SSH-Logs finden sich normalerweise in:
/var/log/auth.log(Debian/Ubuntu)/var/log/secure(CentOS/RHEL)- Mit
journalctl(systemd-Systeme):sudo journalctl -u sshd -f
Achten Sie auf wiederholte fehlgeschlagene Authentifizierungsversuche, Logins von ungewöhnlichen IP-Adressen oder erfolgreiche Logins durch unbekannte Benutzer. Tools wie Logwatch oder Elastic Stack (ELK) können die Log-Analyse und Alarmierung für größere Umgebungen automatisieren.
10. Konfigurieren Sie Firewall-Regeln zur Zugriffsbeschränkung
Eine Firewall ist Ihre erste Verteidigungslinie. Standardmäßig sollte sie den gesamten eingehenden Verkehr blockieren, außer für die Dienste, die Sie explizit freigeben müssen. Für SSH bedeutet dies, Verbindungen nur auf Ihrem gewählten Port (z. B. 2222) und idealerweise nur von bestimmten vertrauenswürdigen IP-Adressen oder Netzwerken zuzulassen.
Beispiel mit UFW (Uncomplicated Firewall):
SSH von einer bestimmten IP-Adresse 192.168.1.100 auf Port 2222 zulassen:
sudo ufw allow from 192.168.1.100 to any port 2222
SSH von einem bestimmten Subnetz 192.168.1.0/24 zulassen:
sudo ufw allow from 192.168.1.0/24 to any port 2222
Beispiel mit Firewalld (CentOS/RHEL):
SSH von einer bestimmten IP-Adresse 192.168.1.100 auf Port 2222 zulassen:
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port=2222 protocol="tcp" accept'
sudo firewall-cmd --reload
Warnung: Wenn Sie einen Server von einer dynamischen IP-Adresse aus verwalten, seien Sie vorsichtig mit strengen Firewall-Regeln. Möglicherweise müssen Sie den Zugriff von einem breiteren Bereich aus erlauben oder ein VPN verwenden.
Zusätzliche Härtungstipps
Über die wesentlichen 10 hinaus sollten Sie diese Direktiven für noch mehr Sicherheit in Betracht ziehen:
MaxAuthTries: Begrenzt die Anzahl der Authentifizierungsversuche pro Verbindung. Standard ist 6. Eine Senkung (z. B. auf3) reduziert die Brute-Force-Chancen. Setzen Sie dies insshd_config.MaxAuthTries 3LoginGraceTime: Begrenzt die Zeit, die einem Benutzer zur Authentifizierung eingeräumt wird. Standard sind 2 Minuten. Eine Senkung (z. B. auf30s) reduziert das Zeitfenster für langsame Angriffe.LoginGraceTime 30sClientAliveIntervalundClientAliveCountMax: Verhindern, dass untätige SSH-Sitzungen unbegrenzt offen bleiben.ClientAliveIntervalsendet alle X Sekunden eine Keepalive-Nachricht. WennClientAliveCountMaxAntworten verpasst werden, wird die Verbindung beendet.ClientAliveInterval 300 ClientAliveCountMax 2Banner: Zeigt eine Warnmeldung vor der Authentifizierung an. Dies dient als rechtlicher Hinweis für potenzielle unbefugte Benutzer.
Erstellen Sie die DateiBanner /etc/issue.net/etc/issue.netmit Ihrer gewünschten Warnmeldung.
Praktische Umsetzung
Beginnen Sie mit den Änderungen, die das größte Risiko beseitigen: Deaktivieren Sie den Root-Login, fordern Sie SSH-Schlüssel, schränken Sie ein, wer sich verbinden darf, und begrenzen Sie die Quellnetzwerke, wenn möglich. Testen Sie jede Änderung mit sshd -t und einer neuen Login-Sitzung, bevor Sie Ihre aktuelle schließen.