SSH ist das Standardwerkzeug für Remote-Administration unter Linux und auf vielen NAS-Systemen. Genau deshalb wird es automatisiert gescannt und mit Login-Versuchen bombardiert. In der Praxis entstehen Vorfälle selten durch „Zero-Days“, sondern durch zu einfache Zugangsdaten, unnötig offene Ports oder fehlende Begrenzungen für Anmeldeversuche. Eine saubere Härtung reduziert die Angriffsfläche, ohne die tägliche Administration unnötig zu verkomplizieren.
Warum SSH so oft kompromittiert wird
Typische Angriffsmuster: Scans, Brute-Force, Credential-Stuffing
Angreifer suchen automatisiert nach Systemen mit offenem Port 22 (oder alternativen Ports). Danach folgen massenhaft Anmeldeversuche: Entweder klassisches Brute-Force (viele Passwörter durchprobieren) oder Credential-Stuffing (geleakte Kombinationen aus E-Mail/Benutzername und Passwort testen). Besonders riskant sind Systeme, auf denen Passwort-Login erlaubt ist und ein Benutzer mit weitreichenden Rechten direkt per SSH erreichbar ist.
Konfigurationsfehler, die teuer werden
Zu den häufigsten Schwachstellen zählen: Root-Login über SSH, unlimitierte Login-Versuche, fehlende Protokollauswertung, zu breite Firewall-Regeln und veraltete Kryptografie-Defaults. Auch scheinbar „kleine“ Nachlässigkeiten wie gemeinsam genutzte Admin-Accounts oder private Schlüssel ohne Passphrase erhöhen das Risiko deutlich.
Schlüsselbasierte Anmeldung statt Passwort-Login
Warum Schlüssel robuster sind
Bei der schlüsselbasierten Anmeldung wird kein Passwort über das Netz geprüft. Stattdessen weist sich der Client mit einem privaten Schlüssel aus; der Server akzeptiert nur Clients, deren öffentlicher Schlüssel in der authorized_keys-Liste hinterlegt ist. Damit werden Brute-Force-Attacken auf Passwörter praktisch wirkungslos, solange der private Schlüssel geschützt bleibt.
Pragmatisches Setup für Admins und Automatisierung
Für Administratoren empfiehlt sich ein eigener Schlüssel pro Person und Gerät. Für Automatisierung (z. B. Deployments/Backups) sollten separate Schlüssel mit minimalen Rechten genutzt werden, damit ein kompromittierter Automations-Host nicht automatisch „Admin auf alles“ bedeutet. Private Schlüssel gehören mit restriktiven Dateirechten gespeichert; bei Workstations ist zusätzlich eine Passphrase sinnvoll, idealerweise mit Agent-Unterstützung.
sshd_config: sichere Defaults ohne Nebenwirkungen
Root-Login sperren und Rechte sauber trennen
Ein zentraler Schritt ist, direkte Root-Anmeldungen zu unterbinden: PermitRootLogin sollte auf „no“ stehen. Administratoren melden sich mit einem normalen Benutzer an und wechseln nur bei Bedarf per sudo zu Root. Das schafft Nachvollziehbarkeit (wer hat was getan) und reduziert die Auswirkung gestohlener Zugangsdaten.
Passwort-Login abschalten – aber erst nach Funktionsprüfung
Erst wenn der Schlüssel-Login getestet ist, sollte Passwort-Login deaktiviert werden: PasswordAuthentication auf „no“. Wichtig: Vor dem finalen Umstellen mindestens eine zweite SSH-Sitzung offen lassen, um sich nicht auszusperren, und einen Out-of-Band-Zugang (Konsole, IPMI, VM-Konsole oder serieller Zugriff) einplanen.
Zugriff gezielt einschränken: AllowUsers/AllowGroups
Statt allen lokalen Accounts den SSH-Login zu erlauben, ist eine Whitelist sinnvoll. Mit AllowUsers oder AllowGroups wird genau festgelegt, welche Benutzer(gruppen) sich anmelden dürfen. Das reduziert die Angriffsfläche, wenn auf dem System Service-Accounts oder temporäre Benutzer existieren.
Netzwerkzugang begrenzen: Firewall, IP-Whitelists, Segmentierung
SSH nur dort öffnen, wo es wirklich gebraucht wird
SSH sollte nicht „für alle“ im Internet erreichbar sein, wenn es nicht erforderlich ist. Sinnvoll ist eine Freigabe nur aus dem Admin-Netz, via VPN oder über einen Jump-Host (Bastion). Auf vielen Setups reicht es, SSH ausschließlich im internen Netz zu exponieren und externe Administration über einen abgesicherten Zugang zu führen. Wer Zero-Trust-Ansätze im Netzwerk umsetzen möchte, kann ergänzend die Prinzipien aus Zero Trust im Heim- und Firmennetz übertragen: explizite Freigaben, minimale Reichweite, klare Zonen.
Port ändern: sinnvoll, aber nur als Zusatz
Ein alternativer Port reduziert Hintergrundrauschen durch Standard-Scans, ersetzt aber keine Härtung. Ohne Schlüssel-Login, Benutzer-Whitelist und Rate-Limits bleibt SSH angreifbar. Port-Änderungen sind deshalb nur ein kleines Puzzleteil – nicht die Hauptmaßnahme.
Angriffe ausbremsen: Rate-Limits, Sperren, Logging
Login-Versuche drosseln und Fehlversuche sichtbar machen
Ein Server sollte auf wiederholte Fehlanmeldungen reagieren: mit Rate-Limits auf Firewall-Ebene (z. B. nftables/iptables oder Cloud-Firewall) und mit Tools, die IPs nach Muster erkennen und temporär sperren (z. B. fail2ban). Zusätzlich sind sinnvolle Log-Einstellungen wichtig, damit ungewöhnliche Muster auffallen (z. B. viele Fehlversuche auf mehrere Accounts).
Protokolle zentral oder zumindest regelmäßig prüfen
Auf einzelnen Maschinen geraten Logs schnell in Vergessenheit. Zentralisierte Auswertung erhöht die Chance, frühe Warnsignale zu sehen (ungewöhnliche Uhrzeiten, neue Quellnetze, plötzliche Login-Spitzen). Für praxisnahe Ansätze zur Log-Korrelation und Alarmierung ist SIEM im Mittelstand ein sinnvoller Einstiegspunkt.
Kryptografie und Client-Hygiene: weniger Angriffsfläche im Detail
Starke Schlüsseltypen und klare Lebenszyklen
Ed25519-Schlüssel sind in modernen Umgebungen ein guter Standard (kurz, schnell, robust). RSA kann weiterhin sinnvoll sein, wenn Kompatibilität benötigt wird, dann aber mit angemessener Schlüssellänge. Unabhängig vom Typ gilt: Schlüssel brauchen einen Lebenszyklus (Erstellung, Verteilung, Rotation, Widerruf). Sobald ein Client kompromittiert ist oder ein Gerät verloren geht, müssen betroffene Schlüssel serverseitig entfernt werden.
Clients absichern: private Keys schützen und weitergeben vermeiden
Private Schlüssel sollten nicht per Chat, Ticket oder E-Mail verteilt werden. Für Teams ist es sauberer, pro Person eigene Schlüssel zu pflegen und Zugriffe über Gruppen/Policies zu steuern. Auf Workstations verhindert eine Passphrase, dass ein gestohlener Laptop sofort zum Serverzugang wird. Bei automatisierten Jobs helfen dedizierte Schlüssel mit eingeschränkten Rechten und separaten Benutzerkonten.
Konkrete Umsetzung in wenigen Schritten
Die folgenden Schritte sind bewusst so gewählt, dass sie in den meisten Linux-Distributionen und vielen NAS-Varianten umsetzbar sind. Vor Änderungen an SSH immer eine Konsole als Fallback bereithalten und nach jeder Teiländerung testen.
- Schlüssel pro Admin erstellen (z. B. Ed25519) und den öffentlichen Schlüssel auf dem Server hinterlegen (authorized_keys).
- In der SSH-Serverkonfiguration Root-Login deaktivieren (PermitRootLogin = no).
- Schlüssel-Login testen, erst dann Passwort-Login deaktivieren (PasswordAuthentication = no).
- SSH-Zugriff über AllowUsers/AllowGroups auf Admin-Accounts begrenzen.
- Firewall-Regeln setzen: SSH nur aus Admin-Netzen/VPN erlauben; keine weltweite Freigabe, wenn vermeidbar.
- Rate-Limits/Sperren aktivieren (Firewall-Rate-Limit oder fail2ban) und Logs regelmäßig prüfen oder zentral auswerten.
NAS und Heimserver: typische Stolpersteine
GUI-Optionen vs. echte Server-Defaults
Viele NAS-Oberflächen bieten SSH als einfachen Schalter an, verstecken aber Details der Serverkonfiguration. Nach Firmware-Updates können Einstellungen zurückgesetzt oder ergänzt werden. Deshalb ist es wichtig, nach Updates kurz zu prüfen, ob die gewünschten Sicherheitsparameter noch aktiv sind (z. B. kein Passwort-Login, keine Root-Anmeldung, Zugriffsbeschränkungen).
Externer Zugriff: lieber VPN oder Jump-Host statt Portweiterleitung
Eine Portweiterleitung am Router macht SSH aus dem Internet sichtbar. Das ist selten zwingend notwendig. Praktischer und sicherer ist ein VPN-Zugang oder ein dedizierter Jump-Host, der streng abgesichert und überwacht wird. Für Heimnetze lohnt sich zusätzlich eine solide Basis-Härtung des Routers und WLANs, damit Admin-Zugänge nicht über ein schwaches Funknetz kompromittiert werden; passende Maßnahmen beschreibt WLAN absichern: Router richtig härten.
Wenn ein SSH-Zugang kompromittiert wurde: saubere Reaktion
Sofortmaßnahmen zur Eindämmung
Bei Verdacht auf unbefugten Zugriff zählt Geschwindigkeit und Systematik: Zugang schließen (Firewall/SSH stoppen), aktive Sessions prüfen, betroffene Accounts sperren und Schlüssel/Passwörter als kompromittiert behandeln. Danach müssen Logs gesichert werden, bevor sie überschrieben werden. In vielen Fällen ist eine Neuinstallation aus vertrauenswürdigen Quellen plus Restore aus sauberen Backups der verlässlichste Weg zurück zu einem bekannten Zustand.
Wiederanlauf ohne Wiederholung des Problems
Nach der Bereinigung sollten die Ursachen technisch abgestellt werden: Passwort-Login deaktivieren, Zugriffe einschränken, Keys rotieren, Updates einspielen und Monitoring verbessern. Wer Remote-Admin unter Windows mit ähnlichen Risiken betreibt, sollte auch den Zugangspfad absichern; eine sinnvolle Ergänzung ist RDP absichern, um laterale Bewegungen und Kontoübernahmen zu erschweren.
| Risiko | Typischer Auslöser | Praktische Gegenmaßnahme |
|---|---|---|
| Brute-Force auf Logins | Passwort-Login aktiv, viele erlaubte User | Schlüssel-Login, Passwort-Login aus, AllowUsers/AllowGroups, Rate-Limits |
| Direkte Privilegienübernahme | Root-Login per SSH erlaubt | PermitRootLogin deaktivieren, sudo mit Protokollierung |
| Unbemerkte Kompromittierung | Keine Log-Auswertung, kein Alarming | Regelmäßige Log-Checks oder zentrale Auswertung/Alarmierung |
| Schlüsselmissbrauch | Gemeinsam genutzte Keys, verlorene Geräte | Pro Person/Gerät eigene Keys, Rotation, Widerruf, Passphrase |
