Läuft in WinSCP, im Flow nur 405: die zwei SFTP-Connectors in Power Automate

Die Zugangsdaten stimmen. In WinSCP verbindest du dich mit genau diesem SFTP-Server, siehst die Ordner, lädst Dateien hoch und runter. Dann baust du denselben Zugang in einen Power-Automate-Cloud-Flow — und beim Testen der Verbindung oder beim ersten Lauf kommt nur ein dürres 405 zurück, oder ein generisches „Bad Gateway”. Kein Hinweis, was fehlt. Kein Stacktrace. Nichts.

Das ist einer der frustrierendsten Fälle in der Power-Platform-Integration, weil das naheliegende Argument — „aber in WinSCP geht’s doch!” — gerade nicht weiterhilft. Dieser Beitrag erklärt, warum, und zwar in drei Schritten: Es gibt zwei SFTP-Connectors (einer ist abgekündigt), ein 405 bedeutet bei SFTP etwas ganz Bestimmtes, und „läuft in WinSCP” beweist weniger, als man denkt. Am Ende steht eine Checkliste, mit der du den Fall systematisch einkreist.

Zwei Connectors, die fast gleich heißen

Der erste Stolperstein sitzt schon in der Connector-Auswahl. In Cloud Flows gibt es zwei von Microsoft verwaltete SFTP-Connectors mit fast identischem Namen:

Connector	Was er ist	Status (Aug. 2026)
SFTP	der alte Connector	abgekündigt – „on its deprecation path”
SFTP – SSH	der aktuelle, empfohlene	aktiv, nutzt intern SSH.NET

Microsoft ist auf der Referenzseite des alten Connectors ungewöhnlich deutlich: „This connector is on its deprecation path, please use the new SFTP-SSH connector.” Alle Aktionen des alten Connectors tragen den Zusatz [DEPRECATED].

Erste Prüffrage also: Nutzt dein Flow „SFTP – SSH” oder noch das alte „SFTP”? Wer aus einem älteren Flow, einer Vorlage oder einer kopierten Solution erbt, hängt schnell am falschen Connector. Und genau hier kann ein Verbindungsversuch gegen den zurückgezogenen Connector schon einen 405 auf den Connection-Test werfen, weil dessen Endpunkt für neue Verbindungen nicht mehr sauber bedient wird. Umstellen auf SFTP – SSH, Verbindung neu anlegen — das ist der erste, billigste Fix.

Was ein 405 bei SFTP technisch wirklich bedeutet

Jetzt die unbequeme Wahrheit, die den meisten Debugging-Sessions fehlt: Ein 405 ist bei diesen Connectors nicht offiziell dokumentiert. Die Learn-Troubleshooting-Sektion von SFTP-SSH kennt 401, 404 und 504 — kein 405. Die dokumentierten Fehlerbilder sind stattdessen „Bad Gateway”, „Key exchange negotiation failed”, „Server HMAC algorithm not found” oder „Server response does not contain SSH protocol identification”.

Warum ist das wichtig? Weil 405 Method Not Allowed ein HTTP-Statuscode ist. Echtes SSH/SFTP auf Port 22 spricht kein HTTP und liefert niemals einen 405. Wenn du also einen 405 siehst, ist das ein starkes Signal, dass gar keine echte SFTP-Verbindung zustande kommt, sondern etwas HTTP-Sprechendes antwortet. Die drei plausibelsten Ursachen:

1. Falscher Endpunkt / falscher Port. Der Connector spricht gegen einen HTTP-Reverse-Proxy, eine WAF oder einen Load Balancer vor dem eigentlichen SFTP-Server (etwa Port 443/80 statt 22), und diese Appliance antwortet auf die eingehende Methode mit „405 Method Not Allowed”. WinSCP zeigt exakt dieses Bild, wenn man es versehentlich auf einen HTTP-Endpunkt richtet. → Host und Port prüfen: wirklich SFTP über SSH auf 22, nicht FTPS/HTTPS?
2. Noch der alte, abgekündigte Connector (siehe oben) — der Connection-Management-Aufruf läuft ins Leere.
3. Verwechslung mit einem Custom Connector. Wer SFTP über einen selbstgebauten HTTP-Custom-Connector nachbildet, erzeugt einen 405, sobald die HTTP-Methode einer Aktion falsch definiert ist (z. B. DELETE statt PUT). Betrifft den Managed-Connector nicht, taucht aber in der Suche als „SFTP 405” auf.

Kurz: Der 405 lenkt dich weg vom SSH-Layer und hin zur Frage „Sprichst du überhaupt mit dem richtigen Ding auf dem richtigen Port?”

Warum es in WinSCP läuft und im Flow nicht

Angenommen, Host und Port stimmen und du bist auf SFTP – SSH — und trotzdem scheitert die Verbindung (dann meist mit „Bad Gateway”, „Key exchange negotiation failed” oder „Server HMAC algorithm not found”). Jetzt greift das eigentliche Kernproblem, und es erklärt auch, warum WinSCP dich in die Irre führt.

Der Connector ist auf die Algorithmen von SSH.NET beschränkt — WinSCP kann deutlich mehr. SFTP-SSH nutzt intern die Open-Source-Bibliothek SSH.NET. Deren unterstützte Verfahren sind in der offiziellen Doku aufgelistet — und diese Liste ist enger als das, was WinSCP mitbringt. Besonders auffällig:

• Key-Exchange (KEX) und Cipher: eine feste, endliche Liste (u. a. curve25519-sha256, ecdh-sha2-nistp256/384/521, diverse diffie-hellman-group…, aes*-ctr/-cbc). Bietet dein Server nur KEX-Verfahren an, die nicht dabei sind, schlägt die Aushandlung fehl — WinSCP dagegen handelt großzügig einen gemeinsamen Nenner aus.
• MAC/HMAC: In der offiziellen Algorithmusliste von SFTP-SSH tauchen gar keine MAC-Algorithmen auf. Genau das erzeugt das dokumentierte „Server HMAC algorithm not found”, wenn der Server nur MACs anbietet, die die Bibliothek nicht kennt.
• Key-Format: SFTP-SSH will RSA- oder DSA-Keys im OpenSSH- oder ssh.com-Format. Ein PuTTY-.ppk — das WinSCP klaglos frisst — muss vorher nach OpenSSH/.pem konvertiert werden. Falsches Format → „Permission denied (publickey)”.
• Host-Key-Fingerprint: SFTP-SSH akzeptiert den Fingerprint nur als MD5 (47 Zeichen, 16 Hex-Paare mit Doppelpunkten). WinSCP zeigt dir standardmäßig einen SHA-256-Fingerprint an — trägst du den ein, wird er abgewiesen.

Die eigentliche Lehre daraus:

„Läuft in WinSCP” beweist nur, dass Server erreichbar ist und die Zugangsdaten stimmen. Es beweist nicht, dass der Connector die vom Server angebotenen Algorithmen (KEX/Cipher/MAC) oder deine Key- und Fingerprint-Formate unterstützt. WinSCP ist der großzügige, breit kompatible Client — SSH.NET ist der limitierende Faktor.

Die offensichtlichen, aber falschen Reflexe

Reflex 1: „Die Zugangsdaten müssen falsch sein.” Nein — dass sie in WinSCP funktionieren, schließt das praktisch aus. Das Problem sitzt fast immer eine Ebene tiefer (Connector-Variante, Port/Proxy, Algorithmen, Key-/Fingerprint-Format), nicht bei User/Passwort.

Reflex 2: „Ich nehme einfach den erstbesten SFTP-Connector.” Das ist die Falle der zwei Namen. Der erstbeste ist oft das abgekündigte „SFTP”. Immer bewusst SFTP – SSH wählen.

Reflex 3: „Ich kopiere den WinSCP-Fingerprint rein.” WinSCP zeigt SHA-256, der Connector will MD5 — der Copy-Paste-Reflex produziert genau den nächsten Fehler. Fingerprint gezielt als MD5 besorgen (siehe unten).

Hands-on: systematisch eingrenzen

Statt zu raten, arbeite die folgende Reihenfolge ab — sie geht von „billig und häufig” zu „selten und teuer”:

1. Connector-Identität prüfen. Steht im Flow „SFTP – SSH” oder „SFTP [DEPRECATED]”? Bei alt: umstellen, Verbindung neu anlegen.
2. Host, Port, Protokoll. Wirklich SSH/SFTP auf Port 22? Ein 405 deutet stark auf ein HTTP-Frontend/Proxy oder einen falschen Port (443/FTPS) hin.
3. Verbindung frisch anlegen und den Key kopieren, nicht abtippen (Doku-Warnung: manuelles Editieren zerschießt Keys). .ppk, ed25519 oder ecdsa? Nach OpenSSH/.pem (RSA) konvertieren.
4. Fingerprint als MD5 besorgen. In WinSCP unter Session → Server/Protocol Information; oder aus dem Public Key:

   ssh-keygen -l -E md5 -f id_rsa.pub

   Zum reinen Isolieren testweise „Disable SSH host key validation” = true setzen — läuft es dann, war der Fingerprint das Problem. (In Produktion wieder aktivieren.)
5. Root folder path explizit setzen — nicht auf / verlassen. Fehlen dort Rechte, kommt „Permission denied” beim Test.
6. Algorithmen abgleichen. Welche KEX/Cipher/MAC bietet der Server an (Server-Config oder WinSCP → Server/Protocol Information)? Gegen die SFTP-SSH-Liste halten. Bietet der Server nur Verfahren, die SSH.NET nicht kennt → Server-seitig ein kompatibles Verfahren aktivieren oder auf den Fallback wechseln (siehe unten).
7. Firewall/IP-Freigabe. Steht eine Firewall davor, die ausgehenden IPs des Managed Connectors der Region freigeben — nicht die IP „deiner” Logic App/Flow, sondern die Connector-IPs. Und: begrenzt der Server die Verbindungen pro Quell-IP, kann der Connector (mehrere parallele Verbindungen) anecken.
8. Gateway nur wenn nötig. Ist der SFTP-Server nur intern erreichbar, braucht der Managed-Connector ein On-premises Data Gateway. Ist der Server öffentlich, kein Gateway auswählen — sonst baust du dir eine zusätzliche Fehlerquelle ein.

Voraussetzungen & Fallstricke von SFTP – SSH

Ein paar Details der Doku, die man vor dem produktiven Einsatz kennen sollte:

• Dateigrößen / Chunking. Aktionen mit Chunking (u. a. Create file, Get file content) schaffen bis 1 GB; ohne Chunking ist bei 50 MB Schluss. Trigger können kein Chunking: Dateien > 50 MB werden übersprungen, „include content”-Trigger holen nur ≤ 15 MB. Muster für große Dateien: Trigger „properties only” + separate Aktion „Get file content”.
• Verbindungs-Caching. SFTP-SSH cacht eine Verbindung bis zu einer Stunde — praktisch für Durchsatz, aber ein Faktor, wenn sich serverseitig etwas ändert.

Nicht jeder SFTP-Server wird unterstützt

Das übersehen viele: Die SFTP-SSH-Doku führt ausdrücklich Server auf, die nicht unterstützt werden — unabhängig davon, ob die Zugangsdaten stimmen. Steht einer davon auf der Gegenseite, ist Frust vorprogrammiert, und kein Fingerprint- oder Key-Trick hilft. Genannt werden u. a.:

• AWS Transfer (AWS SFTP)
• Globalscape
• IBM DataPower
• MessageWay
• OpenText Secure MFT / GXS
• Akamai NetStorage
• FileMage
• VShell
• „SFTP for Azure Blob Storage”

Deshalb lohnt sich der Blick in diese Liste bevor man mit dem Debugging beginnt: Ist der Zielserver dort aufgeführt, führt der Managed-Connector nicht zum Ziel — dann direkt zum Fallback unten.

Der Fallback, wenn die Algorithmen partout nicht passen

Wenn Schritt 6 ergibt, dass Server und SSH.NET keinen gemeinsamen Nenner finden (typisch bei alten oder sehr strikt gehärteten Servern) — oder der Server auf der Liste oben steht —, gibt es einen offiziell empfohlenen Ausweg: eine Standard Logic App mit dem built-in SFTP-Connector statt des Managed-Connectors in Power Automate. Der built-in-Connector bringt eine breitere Cipher-Suite mit, läuft über die VNet-Integration (kein Gateway nötig) und lässt sich beim Scale-out feiner steuern. Microsoft nennt diesen Weg selbst bei Cipher-Inkompatibilität.

Das ist kein Eingeständnis einer Niederlage, sondern die richtige Werkzeugwahl: Power-Automate-Managed-Connector für den Normalfall, Standard-Logic-App-built-in für die harten Fälle.

Grenzen und Ehrliches

• Der 405 selbst bleibt undokumentiert. Alles oben zum 405 ist begründete Herleitung (HTTP-Status → kein echtes SSH), nicht ein von Microsoft dokumentierter Fehlercode. Behandle ihn als Wegweiser Richtung Netzwerk/Port/Connector-Variante, nicht als SSH-Fehler.
• Kein festes Abschaltdatum für den alten Connector. „Deprecation path” heißt: eingefroren, keine neuen Features, irgendwann kein Support — aber Microsoft nennt kein konkretes Enddatum. Nicht darauf verlassen, dass er „noch lange läuft”.
• Community vs. offiziell. Viele 405-Erfahrungsberichte stammen aus Foren (Microsoft Q&A, Power Users, WinSCP-Forum). Als Hinweise wertvoll, als Zusicherung nicht — die belastbaren Fakten (Algorithmen, MD5-Fingerprint, Chunking-Limits) stehen in den unten verlinkten Learn-Seiten.

Unterm Strich: „Läuft in WinSCP, im Flow nur 405” ist selten ein Zugangsdaten-Problem und fast immer eines von Connector-Variante, Port/Proxy oder Algorithmus-/Format-Kompatibilität. Prüfe in dieser Reihenfolge, hol dir den Fingerprint als MD5, konvertiere den Key ins richtige Format — und wenn Server und SSH.NET sich partout nicht einigen, wechsle auf die Standard Logic App mit built-in SFTP. Dann ist der 405 einmalig ein Rätsel und danach eine Checkliste.

Stand: August 2026. Microsoft ändert Connector-Fähigkeiten und Deprecation-Stati regelmäßig — im Zweifel die verlinkte Learn-Seite prüfen. Der 405 ist kein offiziell dokumentierter Fehlercode dieser Connectors, sondern hier als HTTP-Statuscode interpretiert.

Offizielle Quellen

• SFTP – SSH connector (Referenz, Algorithmen, Limits) — unterstützte KEX/Cipher/Host-Key-Verfahren, MD5-Fingerprint, Chunking, nicht unterstützte Server.
• SFTP connector (der abgekündigte) — „on its deprecation path”.
• SSH.NET (die zugrunde liegende Bibliothek) — was der Connector unter der Haube kann.
• Ausgehende IP-Adressen der Connectors — für die Firewall-Freigabe.
• On-premises Data Gateway einrichten — wenn der Server nur intern erreichbar ist.

Siehe auch

• Der Flow ist deployt – und trotzdem aus. Connection References von Dev bis Prod
• Power Automate ohne Portal-Geklicke: Flows mit Claude autonom bauen, testen und fixen