SSH härten: Schutz vor Brute-Force Angriffen

SSH ist ein häufiges Einfallstor. Bots testen Passwörter immer schneller. Deshalb setze ich auf asymmetrische Verschlüsselung und MFA, unabhängig von der Projektgröße.

Das Problem

Brute-Force und Phishing zielen auf Passwörter. In der Standardkonfiguration erlaubt SSH viele Passwortversuche pro Minute. Sobald ein Passwort bekannt ist, gelingt der Zugriff oft in Sekunden.

Die Lösung

SSH-Zugang härten, Passwörter abschalten, MFA aktivieren, Zugriff begrenzen, Kryptografie aktuell halten. Der Effekt entsteht durch die Kombination.

Umsetzung in der Praxis

Authentifizierung

Passwort-Logins sind der erste Hebel. Ich verbiete den Root-Login, erlaube nur Public-Key-Authentifizierung und setze auf Ed25519. In der sshd_config sieht das so aus:

PasswordAuthentication noPermitRootLogin noPubkeyAuthentication yes

Zugriff einschränken

Ich begrenze den Zugang auf definierte Benutzer und kombiniere das mit IP-Restriktionen in der Firewall.

AllowUsers user1 user2

Netzwerkebene

Eine aktive Firewall mit nur benötigten Ports ist Pflicht, ergänzt durch Rate Limiting mit iptables oder nftables. Für schnelle Sperren gegen Brute-Force setze ich fail2ban ein:

# /etc/fail2ban/jail.local[sshd]enabled = trueport = sshlogpath = /var/log/auth.logmaxretry = 5findtime = 10mbantime = 1h

Damit durchsucht fail2ban die Logs und sperrt eine IP-Adresse nach fünf Fehlversuchen in zehn Minuten für eine Stunde.

Kryptografie härten

Ich deaktiviere unsichere Ciphers und erlaube nur moderne Algorithmen:

KexAlgorithms curve25519-sha256Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.comMACs hmac-sha2-512-etm@openssh.com

Als nicht mehr sicher gelten DSA-Schlüssel (ssh-dss), RSA 1024, ssh-rsa mit SHA1, diffie-hellman-group1-sha1 und diffie-hellman-group14-sha1, CBC-Ciphers wie 3des-cbc oder aes128-cbc sowie MACs wie hmac-md5 oder hmac-sha1.

Zusätzlich

MFA gehört für administrative Accounts dazu. VPN oder Portknocking sind zusätzliche Hürden, wenn SSH offen bleiben muss.

MFA mit Google Authenticator

Ich nutze dafür das PAM-Modul google-authenticator und eine TOTP-App wie Google Authenticator. Der SSH-Login ist nur gültig, wenn Schlüssel und Einmalcode passen.

Installation je nach System:

# Debian/Ubuntusudo apt install libpam-google-authenticator# RHEL/CentOSsudo dnf install google-authenticator

Pro Benutzer starte ich die Einrichtung und scanne den QR-Code in der App:

google-authenticator

Die Backup-Codes sichere ich offline. Danach aktiviere ich die PAM-Integration und erzwinge die Kombination aus Schlüssel und TOTP.

# /etc/pam.d/sshdauth required pam_google_authenticator.so

# /etc/ssh/sshd_configChallengeResponseAuthentication yesKbdInteractiveAuthentication yesAuthenticationMethods publickey,keyboard-interactiveUsePAM yes

Je nach OpenSSH-Version ist ChallengeResponseAuthentication bereits durch KbdInteractiveAuthentication ersetzt. Nach einem sudo systemctl reload sshd fragt SSH zusätzlich nach dem TOTP-Code.

Portknocking nutzen

Portknocking versteckt SSH hinter einer geschlossenen Firewall. Erst nach einer definierten Sequenz öffnet die Firewall den SSH-Port für die Quell-IP. Das ist kein Ersatz für harte Authentifizierung, aber eine zusätzliche Hürde.

Eine typische Umsetzung mit knockd sieht so aus:

# /etc/knockd.conf[openSSH]sequence = 7000,8000,9000seq_timeout = 10command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPTtcpflags = syn[closeSSH]sequence = 9000,8000,7000seq_timeout = 10command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPTtcpflags = syn

Wichtig ist, dass SSH in der Firewall standardmäßig geblockt bleibt, knockd als Service läuft und der Client die Sequenz sendet, zum Beispiel mit knock host 7000 8000 9000.

Checkliste

• Passwort-Login aus.
• Root-Login aus.
• Nur Public-Key-Authentifizierung.
• Starke Schlüssel, Ed25519 oder RSA 4096.
• Zugriff auf definierte Benutzer und IP-Adressen begrenzen.
• Firewall aktiv, nur benötigte Ports frei.
• fail2ban aktiv und auf SSH beschränkt.
• Moderne Schlüssel, Ciphers und MACs, unsichere Algorithmen entfernt.
• MFA für administrative Accounts.
• VPN oder Portknocking, wenn zusätzliche Abschirmung nötig ist.

Warum das für Shop-Verantwortliche relevant ist

Wenn ein Angreifer über schwache Admin-Zugänge reinkommt, ist der Schaden selten nur technisch, meist hängen Betrieb, Kundenvertrauen und Umsatz direkt dran.

Gerade bei wachsendem E-Commerce ist dieser Bereich für mich ein Basis-Thema, weil ein sauber gehärteter Zugang viele Folgerisiken früh reduziert.

Wenn du wissen willst, wie stabil eure Sicherheits- und Betriebsgrundlagen aktuell sind, starte mit dem Projekt-Check. Für Symfony- und PHP-Projekte mit konkreten Risiken passt der Symfony Security Audit besser, weil dort Auth, Rollen, Dependencies und Release-Risiken gemeinsam geprüft werden.