SFTP statt FTP für WordPress: auf SSH-Schlüssel umstellen

Öffnen Sie in Ihrem Hosting-Panel die Übersicht der FTP-Konten. Bei vielen WordPress-Websites taucht dort mindestens ein Zugang auf, den niemand mehr zuordnen kann. Vielleicht stammt er von der Agentur, die die Seite gebaut hat, von einem Freelancer, der vor drei Jahren ein Plugin repariert hat, oder es ist ein Testkonto namens ftp1. Bei der Frage SFTP statt FTP ist die Antwort eindeutig: Löschen Sie diese Konten, verzichten Sie auf unverschlüsseltes FTP und geben Sie jeder Person einen eigenen SSH-Schlüssel für SFTP. Diese Anleitung führt Sie in einer Reihenfolge durch die Umstellung, bei der sich niemand aussperrt.

SFTP vs. FTP: Warum unverschlüsseltes FTP verschwinden muss

Klassisches FTP überträgt Benutzername, Passwort und jede einzelne Datei unverschlüsselt. Wer irgendwo auf dem Übertragungsweg sitzt, kann alles mitlesen, etwa im Hotel-WLAN, über einen kompromittierten Büro-Router oder bei einem nachlässigen Netzbetreiber. Dazu gehört auch die wp-config.php mit Ihrem Datenbankpasswort, falls Sie sie jemals per FTP heruntergeladen haben.

Hinzu kommt: FTP-Zugänge liegen komplett außerhalb von WordPress. Die Zwei-Faktor-Authentifizierung für wp-admin schützt sie nicht, und in der WordPress-Benutzerliste tauchen sie nicht auf. Wer ein funktionierendes FTP-Passwort hat, kann eine PHP-Datei hochladen und Code auf Ihrer Website ausführen, ohne die Login-Seite je gesehen zu haben.

Der Protokollwechsel hat klare Grenzen. SFTP hilft nicht, wenn der Laptop mit dem Schlüssel infiziert ist, und gegen ein verwundbares Plugin bewirkt er nichts. Er schließt genau eine Tür: mitlesbare Zugangsdaten und vergessene Zugänge zu Ihrem Dateisystem.

FTP, FTPS und SFTP im Vergleich

Die Namen sorgen regelmäßig für Verwirrung, deshalb hier die Kurzfassung.

FTPS ist das alte FTP-Protokoll, verpackt in TLS. Der Datenverkehr ist damit verschlüsselt, es werden aber weiterhin separate Datenverbindungen geöffnet. Die vertragen sich oft schlecht mit Firewalls und NAT, und das Ergebnis ist der bekannte Fehler „Verzeichnisinhalt konnte nicht abgerufen werden“. SFTP hat trotz des Namens nichts mit FTP zu tun. Es ist ein Subsystem von SSH, läuft über eine einzige verschlüsselte Verbindung und erlaubt die Anmeldung mit SSH-Schlüsseln statt Passwörtern.

Unsere Empfehlung: Nutzen Sie SFTP, wenn Ihr Hoster SSH-Zugang anbietet. FTPS nur als Notlösung. Klassisches FTP gar nicht. In FileZilla stellen Sie im Servermanager das Protokoll auf „SFTP - SSH File Transfer Protocol“. Wenn es FTPS sein muss, wählen Sie die Option, die explizites FTP über TLS verlangt („Require explicit FTP over TLS“). Nehmen Sie nicht „Use explicit FTP over TLS if available“, also die Variante „wenn verfügbar“: Sie fällt stillschweigend auf unverschlüsseltes FTP zurück, sobald TLS scheitert. WinSCP bietet dieselbe Auswahl unter „File protocol“.

Zuerst alte FTP-Konten finden und löschen

Machen Sie eine Bestandsaufnahme, bevor Sie auch nur einen Schlüssel erzeugen. Schauen Sie an diesen Stellen nach:

• Im Bereich FTP-Konten Ihres Hosting-Panels (cPanel, Plesk und vergleichbare Panels haben alle einen).
• Im Bereich SSH-Zugang bzw. SSH-Schlüssel, einschließlich bereits autorisierter Schlüssel.
• Auf einem eigenen Server: Systembenutzer mit Login-Shell (grep -vE 'nologin|false' /etc/passwd) und jede Datei ~/.ssh/authorized_keys.

Notieren Sie für jedes Konto, wer es wofür nutzt. Kann niemand den Inhaber benennen, löschen Sie das Konto. Das Passwort zu ändern reicht nicht. Wurde das Passwort des Haupt-Hostingkontos jemals in einen FTP-Client eingegeben, ändern Sie es ebenfalls. Dieses Passwort ist mindestens einmal unverschlüsselt übertragen worden.

Halten Sie die Bereinigung kurz schriftlich fest: Datum, entfernte Konten, wer es freigegeben hat. Prüfen Sie parallel auf dieselbe Weise die WordPress-Zugänge. Unser Leitfaden zu WordPress-Benutzerrollen und Sicherheit behandelt diese Seite.

SSH-Schlüssel mit Passphrase erzeugen (einer pro Person)

Jede Person erzeugt ihren eigenen Schlüssel auf ihrem eigenen Rechner. macOS, Linux und aktuelle Windows-Versionen bringen OpenSSH mit:

ssh-keygen -t ed25519 -C "anna@example-company.eu"

Übernehmen Sie den vorgeschlagenen Speicherort und vergeben Sie bei der Abfrage eine Passphrase. Lassen Sie die Passphrase nicht weg. Der Befehl erzeugt zwei Dateien:

• ~/.ssh/id_ed25519 ist der private Schlüssel. Er verlässt das Gerät nie.
• ~/.ssh/id_ed25519.pub ist der öffentliche Schlüssel. Diesen geben Sie weiter.

Damit Sie die Passphrase nicht bei jeder Verbindung eintippen müssen, laden Sie den Schlüssel einmal pro Sitzung mit ssh-add ~/.ssh/id_ed25519 in einen Agenten. Unter Windows aktivieren Sie dafür zuerst den Dienst „OpenSSH Authentication Agent“ (deutsch: „OpenSSH-Authentifizierungsagent“). Manche Clients wie PuTTY brauchen das .ppk-Format. PuTTYgen kann den OpenSSH-Schlüssel importieren und eine .ppk-Kopie speichern. Alle Optionen finden Sie im ssh-keygen-Handbuch.

Warum ein Schlüssel pro Person? Weil das Entziehen eines Zugangs dann bedeutet, eine einzige Zeile zu löschen, und weil die Logs zeigen, wessen Schlüssel benutzt wurde. Gemeinsame Schlüssel und gemeinsame Logins machen beides unmöglich. Schaffen Sie sie im Zuge dieser Umstellung ab.

Öffentlichen Schlüssel hinterlegen: Hosting-Panel oder ~/.ssh/authorized_keys

Bei Managed- oder Shared-Hosting öffnen Sie den Bereich SSH-Zugang oder SSH-Schlüssel. Fügen Sie den öffentlichen Schlüssel ein, geben Sie ihm einen eindeutigen Namen und autorisieren Sie ihn, falls das Panel das verlangt (cPanel hat dafür einen eigenen Schritt „Authorize“).

Auf einem eigenen Server hängen Sie den Schlüssel an die authorized_keys-Datei des Benutzers an und setzen strikte Rechte:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat anna.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Funktioniert die Passwortanmeldung noch, erledigt ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host dasselbe vom Rechner der jeweiligen Person aus. Lassen Sie den Kommentar am Ende jeder Schlüsselzeile stehen (anna@example-company.eu). Nur daran erkennen Sie den Schlüssel in zwei Jahren noch.

Schlüssel-Login testen, dann Passwortanmeldung abschalten

Lassen Sie Ihre aktuelle Sitzung oder den Panel-Tab offen. Testen Sie den neuen Schlüssel in einem zweiten Terminal:

ssh -i ~/.ssh/id_ed25519 user@host

Alternativ verbinden Sie sich mit Ihrem SFTP-Client über die Schlüsseldatei. Erst wenn das für alle Personen funktioniert, die Zugang brauchen, deaktivieren Sie die Passwortauthentifizierung. Im Hosting-Panel ist das meist ein Schalter im SSH-Bereich. Finden Sie bei Shared-Hosting keinen, fragen Sie Ihren Hoster, ob sich SSH- und FTP-Logins per Passwort für Ihr Konto abschalten lassen.

Auf einem eigenen Server setzen Sie in /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

Prüfen Sie außerdem die Dateien in /etc/ssh/sshd_config.d/. Manche Cloud-Images liefern eine Drop-in-Datei mit, die PasswordAuthentication yes setzt. Validieren Sie die Konfiguration und kontrollieren Sie den tatsächlich wirksamen Wert, bevor Sie neu laden:

sudo sshd -t
sudo sshd -T | grep -i passwordauthentication
sudo systemctl reload ssh

Auf Red-Hat-basierten Systemen heißt der Dienst sshd.

Ab jetzt gehört zum Offboarding ein fester Schritt: Am Tag, an dem jemand geht, löschen Sie seine Schlüsselzeile.

FS_METHOD und FTP-Zugangsdaten in wp-config.php

Manchmal zeigt WordPress beim Installieren oder Aktualisieren eines Plugins ein Formular „Verbindungsinformationen“ an. Das passiert, weil PHP nicht direkt in die Dateien schreiben kann, und dahinter steckt meist ein Problem mit den Dateieigentümern. Die Ursache erklärt unser Artikel zu WordPress-Dateirechten.

Ein verbreiteter Workaround war, FTP-Daten in die wp-config.php zu schreiben:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_HOST', 'ftp.example.de' );
define( 'FTP_USER', 'webuser' );
define( 'FTP_PASS', 'the-hosting-password' );

Damit laufen die Updates, aber das Hosting-Passwort steht jetzt im Klartext in einer Datei, die PHP bei jedem Aufruf liest. Gelangt die wp-config.php nach außen, über eine Sicherungskopie, einen falsch konfigurierten Server oder ein verwundbares Plugin, ist der Dateizugang gleich mit weg. Suchen Sie nach diesen Konstanten:

grep -nE "FS_METHOD|FTP_(HOST|USER|PASS|SSL|PUBKEY|PRIKEY)" wp-config.php

Führen Sie die Prüfung auch im übergeordneten Verzeichnis aus, denn manche Installationen legen die wp-config.php eine Ebene höher ab. Entfernen Sie die Konstanten und korrigieren Sie die Eigentümer, sodass WordPress direkt schreiben kann. Dann funktioniert FS_METHOD mit 'direct', oder Sie lassen die Konstante ganz weg. 'ssh2' kommt nur infrage, wenn die PHP-Erweiterung ssh2 und ein eigener Schlüssel sauber eingerichtet sind. Löschen Sie anschließend das referenzierte FTP-Konto oder ändern Sie zumindest dessen Passwort. Die WordPress-Dokumentation zu wp-config.php beschreibt alle diese Konstanten. Unsere Checkliste zur Härtung der wp-config.php behandelt die übrigen Einstellungen in dieser Datei.

Das kostenlose Plugin Security Audit & Compliance von secaudit.eu prüft die Website auf offen liegende Geheimnisse und Dateien sowie auf Härtungslücken. So entdecken Sie Zugangsdaten, die an der falschen Stelle liegen. Die Liste der FTP-Konten in Ihrem Hosting-Panel sieht es nicht; die Bestandsaufnahme oben bleibt also Handarbeit.

FAQ

Reicht FTPS, wenn mein Hoster kein SSH anbietet?

Als Notlösung ist es vertretbar, weil der Datenverkehr verschlüsselt ist. Stellen Sie Ihren Client so ein, dass er TLS zwingend verlangt, nutzen Sie pro Person ein starkes, eigenes Passwort und löschen Sie trotzdem die alten Konten. Bietet Ihr Hoster überhaupt keinen SSH-Zugang und kann auch nicht sagen, wann sich das ändert, sollten Sie einen Wechsel des Hosters in Betracht ziehen.

Brauche ich für SFTP SSH-Schlüssel, oder genügt ein Passwort?

SFTP mit Passwort ist bereits weit besser als FTP, weil das Passwort verschlüsselt übertragen wird. Schlüssel sind trotzdem besser. Sie lassen sich weder erraten noch über eine gefälschte Login-Seite abphishen, weil der private Schlüssel Ihr Gerät nie verlässt. Ein öffentlicher Schlüssel auf mehreren Servern ist kein Risiko wie ein wiederverwendetes Passwort, und jeder Schlüssel lässt sich einzeln entfernen.

Was ist, wenn jemand seinen Laptop mit Schlüssel verliert?

Entfernen Sie den öffentlichen Schlüssel dieser Person noch am selben Tag von allen Servern und aus allen Panels. Die Passphrase verschafft Ihnen Zeit, ist aber kein Grund zu warten. Anschließend erzeugt die Person auf ihrem neuen Gerät ein neues Schlüsselpaar.

Ist unverschlüsseltes FTP ein DSGVO-Problem?

Art. 32 Abs. 1 lit. a DSGVO nennt die Verschlüsselung ausdrücklich als Beispiel für eine geeignete Sicherheitsmaßnahme. Unverschlüsselte Logins auf einen Server, auf dem Kunden- oder Kontaktformulardaten liegen, sind daher schwer zu rechtfertigen. Unser Artikel zu Art. 32 DSGVO für WordPress erläutert den Rest der Vorschrift und den risikobasierten Ansatz dahinter.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.