SSH-Security härten: Keys statt Passwörter und mehr

1. Warum Passwort-Authentifizierung über SSH ein dauerhaftes Angriffsziel bleibt

Port 22 gehört zu den am intensivsten gescannten Ports im gesamten öffentlichen Internet. Automatisierte Botnetze durchsuchen kontinuierlich IPv4-Adressräume nach offenen SSH-Diensten und testen anschließend tausende Kombinationen aus gängigen Benutzernamen wie root, admin oder ubuntu und den häufigsten Passwörtern aus geleakten Datenbanken. Tools wie Shodan machen offene SSH-Ports in Sekunden auffindbar, sodass ein frisch aufgesetzter Server mit Passwort-Authentifizierung oft innerhalb weniger Stunden die ersten Brute-Force-Versuche registriert, unabhängig davon, wie unauffällig oder neu die IP-Adresse ist.

Das strukturelle Problem von Passwörtern liegt in der menschlichen Schwäche, nicht in der Kryptografie selbst: Selbst ein zwölfstelliges, zufällig generiertes Passwort schützt wenig, wenn es in einer Phishing-Mail preisgegeben wird oder identisch zu einem in einem anderen Dienst geleakten Passwort ist. Credential-Stuffing-Angriffe nutzen genau diese Wiederverwendung aus und testen Millionen geleakter Kombinationen automatisiert gegen SSH-Server. Ein einziger erfolgreicher Login reicht aus, um vollständige Shell-Kontrolle über den Server zu erlangen, oft mit denselben Rechten wie ein legitimer Administrator, was SSH zu einem der lohnendsten Angriffsziele überhaupt macht.

2. Schlüsselbasierte Authentifizierung mit ed25519 statt Passwörtern

Public-Key-Authentifizierung ersetzt das "etwas, das man weiß" durch "etwas, das man besitzt": Der private Schlüssel verlässt niemals den Rechner des Nutzers, während nur der öffentliche Schlüssel auf dem Server in ~/.ssh/authorized_keys hinterlegt wird. Ein Angreifer, der den Server kompromittiert, findet dort ausschließlich den öffentlichen Teil, der ohne den privaten Gegenpart wertlos ist. Damit entfällt die gesamte Angriffsfläche von Brute-Force- und Credential-Stuffing-Versuchen, weil kein Passwort mehr existiert, das erraten oder aus einem Leak wiederverwendet werden könnte.

Für neue Schlüssel empfiehlt sich der ed25519-Algorithmus gegenüber klassischem RSA: Er basiert auf elliptischer Kurvenkryptografie, erzeugt deutlich kürzere Schlüssel bei gleichwertiger oder höherer Sicherheit, ist resistenter gegen bestimmte Seitenkanalangriffe und rechnet spürbar schneller. Ein RSA-Schlüssel sollte, falls aus Kompatibilitätsgründen noch nötig, mindestens 4096 Bit stark sein, während ein ed25519-Schlüssel bei fester Schlüssellänge bereits ein vergleichbares Sicherheitsniveau wie RSA-3072 oder höher bietet.

Der eigentliche Härtungsschritt ist erst mit PasswordAuthentication no in der sshd_config abgeschlossen, ergänzt um KbdInteractiveAuthentication no, damit auch interaktive Passwortabfragen über PAM keine Hintertür bleiben. Vor dem Deaktivieren muss zwingend eine bestehende SSH-Sitzung offen bleiben und ein Login mit dem neuen Schlüssel in einem zweiten Terminal erfolgreich getestet werden, sonst droht ein vollständiger Lockout bei einem Tippfehler in der Konfiguration.

# Neues ed25519-Schluesselpaar erzeugen, mit Passphrase schuetzen
ssh-keygen -t ed25519 -a 100 -C "deploy@mironsoft.de" -f ~/.ssh/id_ed25519_prod

# Oeffentlichen Schluessel sicher auf den Zielserver kopieren
ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@server.mironsoft.de

# Login testen, BEVOR PasswordAuthentication deaktiviert wird
ssh -i ~/.ssh/id_ed25519_prod deploy@server.mironsoft.de "echo Key-Login erfolgreich"

# ssh-agent nutzen, um die Passphrase nicht bei jedem Connect einzugeben
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_prod

3. Root-Login deaktivieren und sudo mit dediziertem Admin-User nutzen

Der Benutzername root ist auf jedem Linux-System bekannt und daher der erste Login-Name, den automatisierte Angriffe testen. Ein direkter Root-Login über SSH bedeutet zusätzlich, dass jede Aktion auf dem Server unter derselben Identität stattfindet: Es gibt keine Möglichkeit, im Nachhinein nachzuvollziehen, welcher Mensch welchen Befehl ausgeführt hat, wenn mehrere Administratoren dasselbe Root-Passwort oder denselben Root-Schlüssel teilen. PermitRootLogin no in der sshd_config unterbindet den direkten Login vollständig und zwingt jeden Zugriff über einen benannten, individuellen Account.

Der empfohlene Ersatz ist ein dedizierter Admin-User pro Person, der Mitglied der sudo-Gruppe ist und privilegierte Befehle explizit mit sudo anfordert. Das bringt zwei konkrete Vorteile: Erstens protokolliert sudo standardmäßig jeden ausgeführten Befehl mit Zeitstempel und Benutzername in /var/log/auth.log, was forensische Analysen nach einem Vorfall erst möglich macht. Zweitens lässt sich der Zugriff einzelner Personen granular entziehen, etwa beim Ausscheiden eines Mitarbeiters, ohne ein gemeinsam genutztes Root-Passwort für das gesamte Team ändern zu müssen.

Wer aus Kompatibilitätsgründen noch einen schlüsselbasierten Root-Zugriff für Automatisierung benötigt, sollte PermitRootLogin prohibit-password statt no setzen, was Passwort-Logins als Root konsequent blockiert, aber schlüsselbasierte Zugriffe weiterhin erlaubt. Für die überwiegende Mehrheit produktiver Setups ist jedoch ein vollständig deaktivierter Root-Login über SSH, kombiniert mit einem sudo-Workflow, die robustere und besser auditierbare Lösung.

4. Der SSH-Port ändern: echter Sicherheitsgewinn oder Security-Theater?

Das Verschieben von SSH auf einen anderen Port als 22 reduziert messbar die Menge an Log-Rauschen durch automatisierte Massen-Scanner, die primär die Standardports der bekanntesten Dienste durchsuchen. In der Praxis sinkt die Zahl der täglichen Login-Versuche nach einer Portänderung häufig um über 90 Prozent, was /var/log/auth.log deutlich übersichtlicher macht und die Last auf Intrusion-Detection-Systeme reduziert. Dieser Effekt ist real, aber er betrifft ausschließlich unspezifische, breit gestreute Angriffe, nicht gezielte.

Gegen einen Angreifer, der gezielt eine bestimmte IP-Adresse oder Domain angreift, bietet ein geänderter Port keinen nennenswerten Schutz: Ein vollständiger Portscan mit nmap -p- findet einen offenen SSH-Dienst auf jedem beliebigen Port innerhalb weniger Minuten. Sicherheit, die ausschließlich auf der Geheimhaltung einer Konfiguration beruht, gilt als Security by Obscurity und darf niemals die einzige Schutzmaßnahme sein, da sie bei gezielten Angriffen wirkungslos ist und bei falscher Priorisierung sogar zu trügerischer Sicherheit verleitet.

Praktisch spricht daher wenig gegen eine Portänderung als ergänzende Maßnahme, solange sie mit Bedacht eingeführt wird: Firewall-Regeln, Monitoring-Dashboards und Dokumentation müssen konsistent aktualisiert werden, und restriktive Unternehmensfirewalls blockieren mitunter Nicht-Standard-Ports ausgehend. Sinnvoll ist die Portänderung ausschließlich in Kombination mit den wirksamen Maßnahmen aus diesem Artikel wie Key-Auth und fail2ban, niemals als deren Ersatz.

5. fail2ban gegen SSH-Brute-Force-Angriffe konfigurieren

fail2ban überwacht Log-Dateien wie /var/log/auth.log in Echtzeit, erkennt Muster fehlgeschlagener Login-Versuche über reguläre Ausdrücke und sperrt auffällige IP-Adressen temporär über iptables oder nftables. Das Konzept dahinter heißt "Jail": Für jeden überwachten Dienst existiert eine eigene Konfiguration mit Filterregeln und Reaktionsschwellen, wobei die sshd-Jail in den meisten Distributionen bereits als vorkonfigurierte Vorlage mitgeliefert wird und nur aktiviert werden muss.

Die drei zentralen Stellschrauben sind maxretry (Anzahl erlaubter Fehlversuche), findtime (Zeitfenster, in dem diese Versuche gezählt werden) und bantime (Dauer der Sperre). Für produktive SSH-Server hat sich ein Wert von drei bis fünf Fehlversuchen innerhalb von zehn Minuten bewährt, gefolgt von einer eskalierenden Sperrdauer über bantime.increment, die bei wiederholten Verstößen derselben IP-Adresse exponentiell länger wird. Wichtig ist, die eigene Administrations-IP-Range konsequent über ignoreip auszunehmen, um einen versehentlichen Selbst-Lockout bei zu vielen fehlgeschlagenen Testverbindungen zu vermeiden.

Für Server hinter einem Cloud-Load-Balancer oder CDN muss fail2ban die tatsächliche Client-IP aus den korrekten Log-Feldern extrahieren, statt versehentlich die IP des vorgeschalteten Proxys zu sperren. Der aktuelle Sperrstatus lässt sich jederzeit über fail2ban-client status sshd einsehen, was sich gut für ein einfaches Monitoring-Skript oder ein Alerting bei ungewöhnlich vielen gesperrten IP-Adressen eignet.

# /etc/fail2ban/jail.local: sshd-Jail haerten, Ausnahmen definieren
[sshd]
enabled   = true
port      = ssh
filter    = sshd
logpath   = /var/log/auth.log
maxretry  = 4
findtime  = 10m
bantime   = 1h
bantime.increment = true
bantime.factor    = 4
bantime.maxtime   = 1w
ignoreip  = 127.0.0.1/8 203.0.113.0/24

# fail2ban nach Konfigurationsaenderung neu laden
sudo fail2ban-client reload sshd

# Aktuell gesperrte IP-Adressen der sshd-Jail anzeigen
sudo fail2ban-client status sshd

# Eine faelschlicherweise gesperrte IP-Adresse manuell entsperren
sudo fail2ban-client set sshd unbanip 203.0.113.42

Für ein einfaches Security-Dashboard lässt sich der aktuelle fail2ban-Status regelmäßig als strukturierter Report exportieren, etwa über ein Cronjob-Skript, das fail2ban-client status sshd parst und mit den Rohdaten aus auth.log anreichert. Ein solcher Report zeigt auf einen Blick, welche IP-Adressen aktuell gesperrt sind und welche Benutzernamen am häufigsten für Login-Versuche missbraucht wurden.

{
  "report_type": "ssh_brute_force_summary",
  "generated_at": "2026-07-12T06:00:00Z",
  "source": "fail2ban + auth.log",
  "jail": "sshd",
  "window_hours": 24,
  "total_failed_attempts": 4821,
  "unique_attacking_ips": 312,
  "currently_banned_ips": 47,
  "top_attacking_ips": [
    { "ip": "198.51.100.23", "attempts": 214, "usernames_tried": ["root", "admin", "test"], "status": "banned" },
    { "ip": "203.0.113.88", "attempts": 176, "usernames_tried": ["root", "ubuntu"], "status": "banned" },
    { "ip": "192.0.2.140", "attempts": 98, "usernames_tried": ["root"], "status": "banned" }
  ],
  "most_targeted_usernames": [
    { "username": "root", "attempts": 3102 },
    { "username": "admin", "attempts": 611 },
    { "username": "ubuntu", "attempts": 340 }
  ]
}

6. sshd_config härten: Ciphers, MACs, KexAlgorithms und Timeouts

Über die Authentifizierungsmethode hinaus bestimmt die sshd_config auch, welche kryptografischen Algorithmen für die Transportverschlüsselung, die Integritätsprüfung und den Schlüsselaustausch überhaupt zugelassen sind. Standardinstallationen erlauben aus Kompatibilitätsgründen häufig noch veraltete Algorithmen wie CBC-Modi oder diffie-hellman-group1-sha1, die gegen bekannte Angriffe wie den Lucky-Thirteen-Angriff oder unzureichende Schlüssellängen anfällig sind. Eine explizite Allowlist mit Ciphers, MACs und KexAlgorithms beschränkt die Aushandlung auf ausschließlich moderne, als sicher geltende Verfahren wie chacha20-poly1305 und curve25519-sha256.

Neben der Kryptografie reduzieren Verbindungslimits die Angriffsfläche gegen ressourcenbasierte Angriffe: LoginGraceTime begrenzt, wie lange eine offene, aber nicht authentifizierte Verbindung bestehen bleiben darf, bevor sie automatisch getrennt wird, und verhindert damit, dass tausende halboffene Verbindungen den Server lahmlegen. MaxAuthTries begrenzt die Anzahl der Authentifizierungsversuche pro Verbindung auf server-seitiger Ebene, unabhängig von fail2ban, und MaxStartups begrenzt die Zahl gleichzeitig unauthentifizierter Verbindungen insgesamt.

AllowUsers oder AllowGroups schränken zusätzlich ein, welche Systemkonten sich überhaupt per SSH anmelden dürfen, unabhängig von ihren sonstigen lokalen Berechtigungen. Jede Änderung an der sshd_config sollte vor dem Neuladen mit sshd -t auf Syntaxfehler geprüft werden, da ein fehlerhafter Neustart des SSH-Dienstes bei einem Remote-Server ohne Out-of-Band-Zugriff einen vollständigen Aussperrung bedeuten kann. Das Kommandozeilentool ssh-audit prüft eine laufende Konfiguration extern und listet verbleibende Schwachstellen übersichtlich auf.

# /etc/ssh/sshd_config: gehaertete Konfiguration (Auszug)
Port 2222
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Nur moderne, sichere Algorithmen zulassen
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512

# Verbindungs- und Zeitlimits gegen ressourcenbasierte Angriffe
LoginGraceTime 20
MaxAuthTries 3
MaxSessions 4
MaxStartups 10:30:60
ClientAliveInterval 300
ClientAliveCountMax 2

# Nur explizit erlaubte Accounts duerfen sich per SSH anmelden
AllowUsers deploy admin-jsmith
X11Forwarding no
AllowTcpForwarding local

7. SSH-Agent-Forwarding: Risiken und sicherere Alternativen

SSH-Agent-Forwarding erlaubt es, den lokal laufenden ssh-agent samt geladener Schlüssel über eine bestehende SSH-Verbindung an einen entfernten Host weiterzureichen, sodass von dort aus ohne erneute Eingabe der Passphrase auf weitere Server zugegriffen werden kann. Das ist praktisch für mehrstufige Verbindungen über einen Zwischenserver, birgt aber ein konkretes Risiko: Wer Root-Rechte auf dem Zwischenserver hat, sei es ein legitimer Administrator oder ein Angreifer nach einer Kompromittierung, kann während der aktiven Verbindung den weitergeleiteten Agent-Socket ansprechen und im Namen des Nutzers Signaturen mit dessen privatem Schlüssel erzeugen, ohne den Schlüssel selbst jemals zu sehen.

Die robustere Alternative für den klassischen Anwendungsfall "über Server A auf Server B zugreifen" ist ProxyJump (Kurzform -J), das eine Verbindung transparent durch einen Zwischenhost tunnelt, ohne den Agent-Socket auf diesem Host jemals verfügbar zu machen. Ist Agent-Forwarding dennoch unvermeidbar, etwa für Legacy-Workflows, reduziert ssh-add -c das Risiko, indem jede Nutzung des weitergeleiteten Schlüssels eine explizite Bestätigung auf dem lokalen Rechner erfordert, statt stillschweigend zu signieren.

8. Bastion- und Jump-Host-Muster für Production-Zugriff

In einer Bastion-Host-Architektur sind Production-Server niemals direkt aus dem öffentlichen Internet per SSH erreichbar, sondern ausschließlich über einen einzelnen, dediziert gehärteten Zwischenserver, den Bastion- oder Jump-Host. Dieser reduziert die Angriffsfläche der gesamten Server-Flotte auf einen einzigen, konsequent überwachten Eintrittspunkt: Interne Server benötigen keine öffentliche IP-Adresse und keine direkt aus dem Internet erreichbare Firewall-Regel für Port 22 mehr, was klassische Massen-Scans gegen die eigentliche Infrastruktur wirkungslos macht.

Weil der Bastion-Host dadurch selbst zum wertvollsten Angriffsziel wird, muss er mit allen in diesem Artikel beschriebenen Maßnahmen konsequent gehärtet und zusätzlich minimal gehalten werden: keine anderen Dienste, keine gespeicherten Zugangsdaten zu internen Systemen, vollständiges Session-Logging und, wo möglich, Multi-Faktor-Authentifizierung zusätzlich zum Schlüssel. ProxyJump in der clientseitigen ~/.ssh/config macht den Umweg über den Bastion-Host für Entwickler transparent, ohne dass jede Verbindung manuell in zwei Schritten aufgebaut werden muss.

Für größere Server-Flotten lohnt sich zusätzlich der Umstieg von statisch verteilten authorized_keys auf SSH-Zertifikate: Eine interne Certificate Authority signiert kurzlebige Nutzerzertifikate, die Server über TrustedUserCAKeys akzeptieren, ohne dass jeder einzelne öffentliche Schlüssel auf jedem Server gepflegt werden muss. Der Widerruf eines Zugriffs bedeutet dann lediglich, kein neues Zertifikat mehr auszustellen, statt Schlüssel auf hunderten Servern einzeln zu entfernen.

# ~/.ssh/config: Bastion-Host transparent per ProxyJump einbinden

Host bastion
    HostName bastion.mironsoft.de
    User jump-user
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ForwardAgent no

Host prod-app-*
    HostName %h.internal.mironsoft.de
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ProxyJump bastion
    ForwardAgent no
    ServerAliveInterval 60

# Aufruf im Terminal, ProxyJump-Tunnel wird automatisch aufgebaut:
# ssh prod-app-01

9. SSH-Härtung im Vergleich: unsicher vs. gehärtet

Die folgende Übersicht fasst die in diesem Artikel behandelten Maßnahmen gegenüber und macht sichtbar, welchen konkreten Effekt jede einzelne Einstellung auf die Angriffsfläche eines SSH-Servers hat.

10. Zusammenfassung

SSH-Security härten bedeutet in erster Linie, Passwörter durch schlüsselbasierte Authentifizierung mit ed25519 zu ersetzen und PasswordAuthentication no konsequent durchzusetzen, kombiniert mit einem gesperrten Root-Login und einem dedizierten Admin-User mit sudo-Rechten für vollständige Auditierbarkeit. fail2ban ergänzt diese Basis um automatisierten Schutz gegen Brute-Force-Versuche, während eine gehärtete sshd_config mit moderner Kryptografie, engen Verbindungslimits und einer expliziten Allowlist erlaubter Accounts die verbleibende Angriffsfläche weiter reduziert. Eine Portänderung kann das Log-Rauschen sinnvoll reduzieren, ersetzt aber keine dieser Maßnahmen.

Für Umgebungen mit mehreren Servern ist eine Bastion-Host-Architektur mit ProxyJump der konsequenteste Schritt: Nur ein einziger, maximal gehärteter Eintrittspunkt ist überhaupt aus dem Internet erreichbar, während die restliche Server-Flotte ausschließlich intern zugänglich bleibt. In größeren Teams reduzieren SSH-Zertifikate zusätzlich den operativen Aufwand der Schlüsselverwaltung erheblich, weil Zugriffsrechte zentral über eine Certificate Authority statt über verteilte authorized_keys-Dateien gesteuert werden.

11. FAQ: SSH-Security härten