FileZilla: „No supported authentication methods available (server sent: publickey)“ beheben

So sieht die Meldung in FileZilla aus
Fehler: No supported authentication methods available (server sent: publickey)

Der SFTP-Server erlaubt nur die Anmeldung per SSH-Key, FileZilla bietet aber keinen passenden Schlüssel an. So hinterlegst du den Schlüssel richtig und behebst die Meldung in wenigen Minuten.

Kurzfassung

Der Zusatz server sent: publickey verrät die Ursache: Der Server akzeptiert nur SSH-Schlüssel, kein Passwort. FileZilla hat aber keinen Schlüssel angeboten oder einen, den der Server nicht kennt. Stelle im Servermanager die Verbindungsart auf Schlüsseldatei, wähle deinen privaten Schlüssel und sorge dafür, dass der passende öffentliche Schlüssel auf dem Server hinterlegt ist.

So sieht die Meldung aus

Status:   Verbinde mit server.beispiel.de...
Fehler:   Disconnected: No supported authentication methods available (server sent: publickey)
Fehler:   Herstellen der Verbindung zum Server fehlgeschlagen

FileZilla zeigt diese Zeile auch in der deutschen Oberfläche auf Englisch, weil sie direkt vom SFTP-Modul kommt. Verwandte Meldungen mit derselben Ursache:

  • No more authentication methods available, oft nach Authentication required: Es wurde gar kein Benutzername oder keine passende Methode übermittelt. Das passiert auch, wenn das Feld Benutzer leer ist.
  • Permission denied (publickey): dieselbe Meldung, wie sie das Kommandozeilenprogramm ssh ausgibt.
  • Server refused our key: Der Schlüssel wurde angeboten, der Server kennt ihn aber nicht.

Ursachen

Ursache Woran du sie erkennst
Verbindungsart steht auf „Normal“ (Passwort) Servermanager zeigt Passwortfeld statt Schlüsseldatei
Öffentlicher Schlüssel nicht auf dem Server „Server refused our key“ im Protokoll
Falscher Benutzername Schlüssel liegt beim Benutzer web1, angemeldet wird als root
Öffentliche statt private Datei ausgewählt Dateiendung .pub im Feld Schlüsseldatei
Dateirechte auf dem Server zu offen Schlüssel steht in authorized_keys, wird trotzdem abgelehnt
Schlüsseltyp vom Server nicht erlaubt sehr alte Server ohne ed25519 oder neue Server, die ssh-rsa mit SHA-1 ablehnen

Lösung Schritt für Schritt

Servermanager: Verbindungsart „Schlüsseldatei“ mit Pfad zum privaten Schlüssel
Servermanager: Verbindungsart „Schlüsseldatei“ mit Pfad zum privaten Schlüssel
  1. Prüfen, ob du überhaupt einen Schlüssel hast. Im Ordner .ssh deines Benutzerverzeichnisses liegen dann Dateien wie id_ed25519 und id_ed25519.pub. Fehlen sie, erstelle ein Paar: SSH-Key erstellen unter Windows, Mac und Linux.
  2. Öffentlichen Schlüssel auf dem Server hinterlegen. Beim Hoster im Kundenbereich unter „SSH-Schlüssel“ die Zeile aus der .pub-Datei einfügen. Auf einem eigenen Server gehört sie als eigene Zeile in ~/.ssh/authorized_keys des Benutzers, mit dem du dich anmeldest.
  3. Servermanager umstellen. Strg+S, Eintrag wählen, Protokoll SFTP, Verbindungsart Schlüsseldatei. Im Feld Schlüsseldatei die private Datei auswählen (ohne .pub, oder die .ppk).
  4. Benutzernamen kontrollieren. Exakt der Benutzer, in dessen authorized_keys der Schlüssel steht. Bei Hostern ist das meist der SSH- oder SFTP-Benutzer aus dem Kundenbereich, nicht deine Kundennummer.
  5. Verbinden. Fragt FileZilla nach einer Passphrase, ist der Schlüssel geschützt; das ist korrekt. Danach sollte Status: Verbunden erscheinen.

Wenn es weiterhin nicht klappt (eigener Server)

  • Rechte prüfen. OpenSSH ignoriert authorized_keys, wenn andere Benutzer schreiben dürfen:
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys
    chmod go-w ~
  • Zeile prüfen. Der Schlüssel muss in einer einzigen Zeile stehen. Beim Kopieren aus manchen Editoren entstehen Zeilenumbrüche; dann wird er nicht erkannt.
  • Server-Log lesen. sudo journalctl -u ssh -n 50 (Debian/Ubuntu) bzw. -u sshd zeigt, warum ein Schlüssel abgelehnt wurde, zum Beispiel „Authentication refused: bad ownership or modes“.
  • Mit der Kommandozeile gegenprüfen. ssh -v [email protected] listet, welche Schlüssel angeboten werden und welche Methoden der Server erlaubt. Klappt es dort, liegt der Fehler in der FileZilla-Konfiguration.
  • Passwort-Login nur vorübergehend erlauben. Wer sich ausgesperrt hat, kann über die Konsole des Hosters (VNC/Rescue) in /etc/ssh/sshd_config kurz PasswordAuthentication yes setzen, den Schlüssel hinterlegen und es danach wieder abschalten.

Global statt pro Server: Schlüssel in den Einstellungen

Unter Bearbeiten → Einstellungen → Verbindung → SFTP kannst du Schlüssel global hinzufügen. FileZilla probiert sie dann bei jeder SFTP-Verbindung mit Verbindungsart Normal oder Interaktiv automatisch durch. Das ist praktisch bei vielen Servern mit demselben Schlüssel, kann aber bei Servern mit begrenzten Login-Versuchen zu „Too many authentication failures“ führen. Dann lieber pro Server die Schlüsseldatei eintragen.

Häufige Fragen

Frage antippen, um die Antwort zu öffnen.

Mein Hoster hat Passwort-Login abgeschaltet. Ist das normal?

Bei Managed-Servern und Cloud-VPS zunehmend ja, weil Passwörter das häufigste Einfallstor für Brute-Force-Angriffe sind. Bei klassischem Webhosting ist Passwort-Login per SFTP meist weiter erlaubt.

Kann FileZilla OpenSSH-Schlüssel lesen?

Ja. FileZilla nutzt intern das PuTTY-Format (.ppk), erkennt aber OpenSSH-Schlüssel und bietet an, sie umzuwandeln. Die Originaldatei bleibt dabei erhalten.

Hilft ein anderer Port?

Nein. Die Meldung zeigt, dass die Verbindung zum SSH-Dienst steht; es scheitert erst die Anmeldung. Port und Firewall sind in Ordnung.