Authentifizierungsprotokolle von einem neuen VPS: 200 „root“-/„admin123“-Versuche in vier Stunden – Roboter, kein persönliches Ziel. Der Server fällt nicht aufgrund von Zero-Day-SSH aus, sondern weil PasswordAuthentication ja nach der Installation immer noch in der Nähe war. Vier Gewohnheiten hätten 95 % dieser Fläche geschlossen.
SSH ist die Verwaltungstür Ihres VPS. Bei einem kleinen Projekt ist es oft das Einzige. Für die Sicherung ist kein Sicherheitszentrum erforderlich, sondern grundlegende Disziplin.
Automatische Scans zielen jederzeit auf den globalen Port 22 ab. Die gute Nachricht: Sie suchen nach Standardwerten – Root-Passwörtern, schwachen Schlüsseln, veralteten Diensten. Vier gut angewandte Gewohnheiten reduzieren die Oberfläche drastisch, ohne dass exotische Hilfsmittel erforderlich sind. Koppeln Sie sie mit der VPS-Firewall und regelmäßigen Updates.
Gewohnheit 1: Nur Schlüsselauthentifizierung
Generieren Sie lokal einen Ed25519-Schlüssel und stellen Sie den öffentlichen Schlüssel unter „~/.ssh/authorized_keys“ für einen dedizierten Benutzer bereit. Stellen Sie in „/etc/ssh/sshd_config“ „PasswordAuthentication nein“, „PubkeyAuthentication ja“, „PermitRootLogin nein“ ein. Testen Sie eine neue Sitzung, bevor Sie die alte schließen, und laden Sie dann „sshd“ neu.
Ein Schlüssel ohne Passphrase auf einem gestohlenen Laptop = Hauptschlüssel. Passphrase oder Hardware-Token für die Produktion.
Gewohnheit 2: Nicht-Root-Benutzer plus Sudo
Erstellen Sie „deploy“ oder „admin“ in der Sudo-Gruppe. Direktes Rooten verboten; Vorgänge über „sudo“ protokolliert. Deaktivieren Sie Cloud-Image-Demokonten.
Gewohnheit 3: fail2ban (oder gleichwertig)
Gefängnis „sshd“ – IP-Adresse nach N Fehlern sperren. Koppeln Sie mit Firewall restriktiv. Office-IP-Whitelist, falls behoben. Verlassen Sie sich nicht nur auf die Änderung von Port 22 – die Scans decken den gesamten Bereich ab.
Gewohnheit 4: Aktualisierung und minimale Oberfläche
Automatische Sicherheitskorrekturen („unattended-upgrades“). Deinstallieren Sie unnötige Dienste, die zuhören. „MaxAuthTries 3“, „AllowUsers bereitgestellt“, wenn kleines Team.
Bastion- und Teamzugang
Multiserver: eine Bastion SSH (eingeschränkte IP-Adresse) oder WireGuard VPN; Die Produktion sollte nach Möglichkeit kein öffentliches SSH verfügbar machen. Verschiedene Staging-/Produktionsschlüssel. Schlüssel bei Mitarbeiterabgang widerrufen – Bereitstellungsgeheimnisse umfasst CI-SSH-Schlüssel.
| Schlecht | Besser |
|---|---|
| root + Passwort | Benutzer + Schlüssel + Sudo |
| überall der gleiche Schlüssel | Schlüssel nach Umgebung |
| SSH-Welt 0.0.0.0/0 | IP-Administrator-Firewall |
Über SSH hinaus: Vergessen Sie die Anwendung nicht
Das Härten von SSH ist kein Ersatz für das Patchen von WordPress, das Schließen von exponiertem phpMyAdmin oder das Entfernen von „.env“ aus dem Repository – siehe Bereitstellungsgeheimnisse. Viele kleine VPS-Kompromisse treten nach erfolgreicher SSH-Härtung durch Anwendungs- oder Anmeldedatenlecks auf. Die vier Gewohnheiten bleiben notwendig; Sie allein reichen nicht aus.
Oben: Gehärtetes SSH schützt die Anwendung nicht
Entscheide dich und gehe ohne blinden Fleck voran
Generieren Sie den Ed25519-Schlüssel mit Passphrase. Erstellen Sie einen Sudo-Benutzer und testen Sie die Schlüsselanmeldung. Deaktivieren Sie die Passwortauthentifizierung und die SSH-Root-Anmeldung. Aktivieren Sie fail2ban und die Firewall, die Port 22 einschränkt. Dokumentieren Sie den Zugriff auf die Fallback-Konsole. Vergleichen Sie Hosts mit der Konsolenrettung über das Verzeichnis.
Häufig gestellte Fragen
RSA-Schlüssel oder Ed25519?
Ed25519 wird für einen neuen VPS empfohlen: kurzer Schlüssel, modern und schnell bereitzustellen. RSA 4096 ist immer noch akzeptabel, wenn Sie eine ältere Umgebung unterstützen müssen. Schützen Sie auf einem Laptop den privaten Schlüssel mit einer Passphrase – oder einem gesperrten SSH-Agenten beim Abmelden.
Root-SSH vollständig deaktivieren?
Ja, sobald ein Sudo-Benutzer in einer neuen parallelen Sitzung erstellt und getestet wurde. Halten Sie die Host-Konsole (KVM oder seriell) zugänglich: Ein Fehler in „sshd_config“ kann Sie vor der nächsten Bereitstellung ausschließen. Testen Sie die Schlüsselanmeldung, bevor Sie die Root-Sitzung schließen.
reicht fail2ban aus?
Nicht allein. fail2ban ergänzt die Sperrung von Schlüsseln und Passwörtern durch das Sperren von IP-Adressen nach wiederholten Fehlern. Legen Sie die Sperrdauer fest und setzen Sie die feste IP-Adresse des Büros auf die Whitelist, sofern Sie eine haben. Andernfalls besteht die Gefahr, dass Sie nach Ihren eigenen Tests gesperrt werden.
SSH auf mehreren Servern: Wie organisieren?
Verwenden Sie separate Schlüssel pro Umgebung (Staging, Produktion), einen „Host“-Block in „~/.ssh/config“ pro Server und ein Bastion- oder WireGuard-VPN für die Produktion. Beschränken Sie Port 22 über die VPS-Firewall auf autorisierte Admin-Adressen; die Schlüssel entziehen, wenn ein Mitarbeiter geht.
Sicheres SSH: vier offensichtliche Gewohnheiten – Schlüssel, kein Root-Passwort, sudo, fail2ban – die zu viele VPS erst nach dem ersten erfolgreichen Scan durchsetzen.