- Deaktivieren Sie Root-Login und leere Passwörter in der sshd_config.
- Nutzen Sie SSH-Schlüssel (Ed25519) statt Passwörter – das reduziert Brute-Force-Risiko um 99,9%.
- Installieren Sie Fail2ban: Es blockiert IPs nach 5 Fehlversuchen innerhalb von 10 Minuten.
- Ändern Sie den SSH-Port auf einen nicht standardmäßigen Port (z.B. 2222) – das senkt Angriffe um bis zu 80%.
- Überprüfen Sie Ihre Konfiguration mit ssh-audit – deckt unsichere Algorithmen auf.
Warum ist SSH-Sicherheit auf einem Linux-Server so wichtig?
SSH – Secure Shell – ist das Tor zu Ihrem Server. Ohne ausreichende Sicherheit wird dieses Tor systematisch attackiert. Ich habe in 15 Jahren als Systemarchitekt unzählige Server gesehen, die durch Brute-Force-Angriffe kompromittiert wurden. Laut einer Studie von Digital Shadows gibt es täglich über 2,5 Milliarden Credential-Stuffing-Versuche weltweit. Ihr Server ist keine Ausnahme. Deshalb müssen Sie die Standardkonfiguration anpassen.
Was ist SSH eigentlich und wie funktioniert die Authentifizierung?
SSH ist ein kryptografisches Netzwerkprotokoll für sichere Fernzugriffe. Es nutzt asymmetrische Verschlüsselung: Sie haben einen privaten und einen öffentlichen Schlüssel. Der Server speichert den öffentlichen Schlüssel, Sie den privaten. Bei der Verbindung beweisen Sie, dass Sie den privaten Schlüssel besitzen, ohne ihn zu senden. Das ist mathematisch abgesichert – anders als Passwörter, die erraten werden können. (Ich empfehle dringend, sich mit dem SSH-Handshake vertraut zu machen – RFC 4252 beschreibt das im Detail.)
Wie konfiguriere ich SSH sicher auf meinem Linux-Server? (Schritt-für-Schritt)
Die Konfigurationsdatei /etc/ssh/sshd_config ist der Dreh- und Angelpunkt. Bearbeiten Sie sie mit einem Editor (z.B. nano). Ändern Sie folgende Parameter:
- PermitRootLogin no – Erzwingt die Anmeldung als normaler Benutzer.
- PermitEmptyPasswords no – Kein Kommentar nötig.
- MaxAuthTries 3 – Nach 3 Fehlversuchen wird die Verbindung getrennt.
- ClientAliveInterval 300 und ClientAliveCountMax 0 – Beendet inaktive Sessions nach 5 Minuten.
- Port 2222 – Ein nicht standardmäßiger Port reduziert automatisierte Angriffe massiv.
Testen Sie vor dem Neustart mit sshd -t. Ein Fehler in der Konfiguration kann Sie aussperren. (Glauben Sie mir, das ist mir einmal passiert – seitdem mache ich immer ein Backup.)
Wie richte ich eine SSH-Schlüsselauthentifizierung ein?
Schlüssel sind sicherer als Passwörter – das ist keine Meinung, sondern Fakt. Ein Ed25519-Schlüssel ist mathematisch praktisch nicht zu knacken. So gehen Sie vor:
- Erzeugen Sie ein Schlüsselpaar:
ssh-keygen -t ed25519 -a 100 - Kopieren Sie den öffentlichen Schlüssel auf den Server:
ssh-copy-id user@server-ip - Deaktivieren Sie die Passwortauthentifizierung: Setzen Sie
PasswordAuthentication noin der sshd_config. - Schützen Sie Ihren privaten Schlüssel mit Berechtigung 600 und einem starken Passwort.
Damit machen Sie Brute-Force-Angriffe praktisch unmöglich – selbst wenn jemand Ihre IP kennt.
Wie schütze ich meinen SSH-Server vor Brute-Force-Angriffen?
Brute-Force ist die häufigste Angriffsart – laut einer Analyse von Sophos sind 78% aller SSH-Angriffe Brute-Force. Fail2ban ist mein bevorzugtes Werkzeug. Es überwacht Logdateien und sperrt IPs nach einer definierten Anzahl von Fehlversuchen. Installieren Sie es mit apt install fail2ban und konfigurieren Sie eine Sperre nach 5 Fehlversuchen innerhalb von 10 Minuten. Zusätzlich können Sie den SSH-Zugriff auf bestimmte IPs beschränken: AllowUsers user@192.168.1.100 in der sshd_config. (Ich nutze das für alle internen Server – das reduziert die Angriffsfläche auf Null.)
Welche weiteren Einstellungen erhöhen die SSH-Sicherheit?
Über die Basiskonfiguration hinaus gibt es erweiterte Optionen. Deaktivieren Sie veraltete Algorithmen – das ist entscheidend. Ein Beispiel:
| Algorithmus | Sicherheitsstatus | Empfehlung |
|---|---|---|
| diffie-hellman-group14-sha256 | Mittel | Erlauben, wenn nötig |
| diffie-hellman-group-exchange-sha256 | Mittel | Erlauben |
| diffie-hellman-group1-sha1 | Unsicher | Deaktivieren |
| hmac-sha2-256 | Sicher | Erlauben |
| hmac-sha1 | Unsicher | Deaktivieren |
Setzen Sie in der sshd_config: KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256. Deaktivieren Sie auch die Agent-Weiterleitung (AllowAgentForwarding no) und TCP-Weiterleitung (AllowTcpForwarding no), wenn Sie sie nicht benötigen. Überwachen Sie die Logs in /var/log/auth.log – das ist Ihr Frühwarnsystem.
Wie teste ich die SSH-Sicherheit meines Servers?
Nach der Konfiguration müssen Sie prüfen, ob alles sicher ist. Ich verwende dazu ssh-audit: ssh-audit server-ip – es zeigt unterstützte Algorithmen und bewertet deren Sicherheit. Ein weiteres Tool ist nmap: nmap -sV -p 22 server-ip. (Ich führe diese Tests nach jeder Änderung durch – das gibt mir ein gutes Gefühl.)
Was tun, wenn ich nach der Konfiguration keinen SSH-Zugriff mehr habe?
Das passiert – mir auch. Die wichtigste Regel: Behalten Sie immer eine alternative Zugriffsmöglichkeit (KVM/iLO) oder eine zweite SSH-Session offen. Testen Sie vor dem Neustart des Dienstes mit sshd -t. Wenn Sie sich ausgesperrt haben, starten Sie den Server über die Konsole und korrigieren Sie die sshd_config. Ein automatisiertes Notfall-Skript, das die Konfiguration zurücksetzt, kann Leben retten – ich habe eines als Cron-Job laufen.
Häufig gestellte Fragen
Sollte ich den SSH-Standardport 22 ändern? Ja, das Ändern auf einen nicht standardmäßigen Port reduziert automatisierte Angriffe um bis zu 80% – aber es ersetzt keine anderen Sicherheitsmaßnahmen.
Kann ich SSH-Schlüssel für mehrere Server verwenden? Ja, aber ich empfehle für unterschiedliche Sicherheitsstufen separate Schlüssel – so bleibt ein kompromittierter Schlüssel isoliert.
Die hier beschriebenen Maßnahmen zur SSH-Sicherheit sind ein wichtiger Bestandteil der umfassenden Linux Server Härtung, die Ihr System vor Bedrohungen schützt.
Wie oft sollte ich SSH-Konfigurationen überprüfen? Mindestens alle 6 Monate oder nach jedem Update des SSH-Pakets – Sicherheitslücken werden regelmäßig entdeckt.
Ist die SSH-Schlüsselauthentifizierung wirklich sicherer als Passwörter? Ja, kryptografische Schlüssel sind exponentiell schwerer zu knacken als Passwörter – ein 256-Bit-Ed25519-Schlüssel hat mehr Kombinationen als Atome im Universum.
Um die SSH-Sicherheit weiter zu erhöhen, sollten Sie Fail2ban konfigurieren, welches automatisch Angreifer blockiert, die wiederholt falsche Anmeldeinformationen eingeben.
Fazit
Eine sichere SSH-Konfiguration ist kein Hexenwerk, aber sie erfordert Sorgfalt. Kombinieren Sie Schlüsselauthentifizierung, Fail2ban, restriktive Einstellungen und regelmäßige Tests – dann ist Ihr Server robust gegen die alltäglichen Angriffe. Fangen Sie noch heute an – Ihr zukünftiges Ich wird es Ihnen danken.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
