Secure FTP geht nicht mehr

[Eris]

Ich hab die libssh2.dll getauscht und es schein alles bestens zu funktionieren, danke.

[ghisler(Author)]

Freut mich, danke für die schnelle Rückmeldung!

[hpmuetzle]

Wegen personellen Engpässen kann ich erst jetzt wieder Rückmeldung geben. Noch im Mai 2022 hatten wir bei eins einige Versuche (z.B. ssh_ed25519 deaktiviert) durchgeführt. Leider ohne Erfolg. Zu der Zeit war mir auch aufgefallen, dass im Plugin libssh2.dll die Version 1.8.1_DEV im Einsatz war. Die aktuellste Version vom 29.08.2021 ist ja die 1.10.0 und in den Releasenotes sind Hinweise zu Bugfixes bzgl. key exchange on Windows zu finden. Diese Erkenntnisse hatte ich leider noch nicht Forum weitergegeben. Die Beta-Version sftpplug300b1 mit der aktuellen libssh2.dll funktioniert bei uns auch tadellos. Vielen Dank auch von mir.

[ghisler(Author)]

Danke für die Rückmeldung! Ich habe die Version 3.0 final nun auf unserer Pluginseite bereitgestellt:
https://www.ghisler.com/dplugins.htm#dateisys

Diese zeigt zusätzlich im Log die verwendeten Verschlüsselungsmethoden der Verbindung an.

[JOUBE]

Ich habe die Version 3.0 final nun auf unserer Pluginseite bereitgestellt

Die Version funktioniert hier nicht (siehe log):

Code: Select all

libssh2_userauth_publickey_fromfile: PUBLICKEY_UNVERIFIED (19)
Fehler: Authentifizierung via Benutzerzertifikat fehlgeschlagen!

[ghisler(Author)]

Siehe meine Rückfrage im Plugin-Thread.

[JOUBE]

Mit der neuen Version 3.01 - auf der Pluginseite bereitgestellt (SFTP 3.01 2022/08/24) - ist alles wieder ok. Die zusätzlichen Infomationen im log sind nützlich (es dürften sogar gerne noch mehr werden: Plugin-Version, libssh2.dll-Version, Startzeit, Infos zum verwendeten Key (filename))

JO"Danke"UBE

[Duese]

Guten Abend und Gruß an die Gemeinde,
der letzte Post hier liegt auch schon einige Tage zurück. Jetzt aber bitte nicht lachen...

Ich wollte nach etwas über einem Jahr (eher 1-½ Jahre) mit meinem Windows XP Rechner wieder meine sFTP Verbindung zu meiner Homepage herstellen, aber leider ging es nicht mehr. Die libssh2.dll-Version dafür ist einfach zu alt. Habe dann gesehen, dass es die neuere 2.9er Version statt meiner 2.5er gibt, aber leider ist diese auch schon wieder zu alt.

Darauf hin habe ich notgedrungen das aktuelle Plugin 3.05 auf meinem anderen Windows 10 Rechner installiert. Damit klappt die Sache wenigstens wieder. Dennoch wäre es für mich wichtig dass die sFTP-Verbindung auch auf dem XP-Rechner funktioniert. Vielleicht stehe ich damit nicht ganz alleine auf weiter Flur... Deshalb meine Frage: Gibt es da vieleicht doch noch eine Lösung für dieses Problem?

LG, Düse

[Dalai]

2Duese
Ob die Verbindung klappt, hängt ganz entscheidend vom SFTP-Server ab. An deiner Stelle würde ich die Verbindung auf dem Win10-Rechner mit derselben alten Plugin-Version testen. Das kann man auch mit verschiedenen Versionen nacheinander tun. Dann weißt du ob es grundsätzlich funktioniert und ggf. auch mit welcher Version. Es kann durchaus sein, dass der Server bestimmte Verschlüsselungsalgorithmen voraussetzt, die Version 2.90 nicht kennt.

Ich hab jedenfalls keine Probleme, mit einer alten Version des Plugins auf meinen Pi im LAN zuzugreifen.

[Duese]

Hallo @Dalai
Danke für Deine Antwort. Inzwischen habe ich mir die sFTP-Sache für Windows XP nochmal näher angeschaut. Hierzu weitere Infos.
• Server: hosting.telekom.de
• Algorithmus des Server-Schlüssels: ssh-ed25519 / ECDSA
Außerdem ist mir aufgefallen, dass sich der Fingerprint-Key am 03.07.2024 geändert hat. In der "sftpplug.ini" war noch der alte Schlüssel drin. Also habe ich den aktuellen Key manuell aktualisiert. Leider hat damit die sFTP-Verbindung auch nicht funktioniert.

In der README aus dem sFTP-Plugin - Release, version 3.05 final ist folgender Text zu finden:
If you use Windows XP or older, please get the other release of this plugin with libssh2.dll linked to OpenSSL.
Habe daraufhin mit OpenSSL ein wenig experimentiert, aber auch erfolglos. Die letzte Version von OpenSSL für XP ist v1.0.0d vom 04.03.2011, was definitiv auch viel zu alt ist. Spätere Versionen unterstützen dann nur noch Windows 2000 bis Windows 10.

So wie es aussieht, werde mich mich wohl leider mit dem Gedanken verabschieden müssen auf meinem XP-Rechner ein sFTP-Plugin für Total Commander nutzen zu können.

Grüße, Düse

[Dalai]

In der "sftpplug.ini" war noch der alte Schlüssel drin. Also habe ich den aktuellen Key manuell aktualisiert.

Warum? Wenn der Fingerprint ein anderer ist, fragt das Plugin (wie jeder andere SSH-Client auch), ob die Verbindung fortgesetzt werden soll. Wenn man das bestätigt, wird der aktuelle Fingerprint eingetragen.

In der README aus dem sFTP-Plugin - Release, version 3.05 final ist folgender Text zu finden:
If you use Windows XP or older, please get the other release of this plugin with libssh2.dll linked to OpenSSL.
Habe daraufhin mit OpenSSL ein wenig experimentiert, aber auch erfolglos.

Bitte genau lesen. Man soll die andere Version/Variante des Plugins benutzen, bei der die beiliegende libssh2.dll gegen OpenSSL gelinkt ist. Da steht nichts davon, dass man ein (externes) OpenSSL braucht.

Die letzte Version von OpenSSL für XP ist v1.0.0d vom 04.03.2011, was definitiv auch viel zu alt ist. Spätere Versionen unterstützen dann nur noch Windows 2000 bis Windows 10.

Windows 2000 ist älter als XP. Wenn die Angabe also lautet "2000 bis 10", dann beinhaltet das XP.


Leider hast du keine Angaben zu den von mir vorgeschlagenen Tests gemacht, was die alte Version des Plugins unter einem neueren OS tut.

[Duese]

Wenn der Fingerprint ein anderer ist, fragt das Plugin (wie jeder andere SSH-Client auch), ob die Verbindung fortgesetzt werden soll. Wenn man das bestätigt, wird der aktuelle Fingerprint eingetragen.

Die Antwort ist ganz einfach: Das Plugin hat mich leider NICHT gefragt, ob die Verbindung fortgesetzt werden soll ...

Bitte genau lesen. Man soll die andere Version/Variante des Plugins benutzen.

Hmm... Vieleicht habe ich ja auch zuviel gelesen und deswegen nicht alles korrekt verstanden. Zwischenzeitlich habe ich auch herausgefunden, dass man kein externes OpenSSL braucht. Ich schreibe hier mal was ich genau gemacht habe:

• Aus den "Plugins zu Total Commander" habe ich die separate Version für XP, welche nur die OpenSSL-DLLs benötigt (alte Version 2.90), heruntergeladen.
• Die im ZIP-Archiv beinhaltet "libssh2.dll vom 30.06.2021". Dieses habe ich in den Unterordner "sftpplug" vom Total Commader kopiert.
• Als nächstes habe ich die "openssl-1.0.2u-i386-win32.zip" aus der TC Webseite heruntergeladen.
• Die im Archiv befindlichen zwei DLLs einschl. der "openssl.exe", alle mit Datum vom 21.12.2019, habe ich in das TC Installationsverzeichnis kopiert, wobei die EXE vermutlich gar nicht benötigt wird.

Leider funktioniert das nicht unter Windows-XP, bzw. nicht mehr seit Anfang Juli 2024.

Windows 2000 ist älter als XP. Wenn die Angabe also lautet "2000 bis 10", dann beinhaltet das XP.

Da gebe ich Dir natürlich recht. Eigentlich wollte ich damit auch ganz was anderes Sagen, aber es waren einfach viele Gedanken gleichzeitig in meinem Schädel, wodurch es wohl einen Knoten gab.
Sagen wollte ich eigentlich nur, dass das sFTP Plugin 3.05 leider nur für Windows Vista, 7, 8, 8.1, 10, und 11 ist, aber nicht mehr für Win-XP.

Es kann durchaus sein, dass der Server bestimmte Verschlüsselungsalgorithmen voraussetzt, die Version 2.90 nicht kennt.

Genau das vermute ich auch stark. Die Telekom hat am 03.07.2024 wohl nicht nur den Fingerprint geändert, sondern sicherlich am Verschlüsselungsalgorithmus rumgeschraubt. Sonst würde es auch noch unter XP laufen.

Leider hast du keine Angaben zu den von mir vorgeschlagenen Tests gemacht, was die alte Version des Plugins unter einem neueren OS tut.

Ja, mit Absicht. Ich bin froh, dass es auf meinem Win-10 Rechner funktioniert und will daher jetzt keine Experimente machen. Eben nach dem Motto "Don't touch a running system"

Ohne einer neuen sFTP-Version 3.05, welche auch noch auf Win-XP läuft, wird es wohl kaum noch eine Lösung dafür geben.

[JOUBE]

Ich habe im SFTP-Plugin bei konfigurierten Verbindungen in den Einstellungen oft einen Zielpfad mit angegeben in der Zeile "Verbinden mit Server". Zum Beispiel:

Code: Select all

IP:Port/Pfad/

Wenn ich dann auf dem Server "Pfad" in "Pfad2" änderte, so dass "Pfad" auf dem Server nicht mehr vorhanden ist, beendet sich der Verbindungs-Versuch scheinbar beim Aufruf dieser Verbindung in der SFTP-Auswahl ohne eine offensichtliche Fehlermeldung. Im SFTP-Log kann man dann aber lesen: "Failed opening remote file"

[ghisler(Author)]

Bei mir wird einfach ein leeres Verzeichnis angezeigt. Wie sieht denn das Verbindungslog aus?
Hier:
Verzeichnis einlesen: \bad
ls -la --time-style="+>>%Y%m%d_%H%M%S" /bad/
ls: cannot access '/bad/': No such file or directory

export LC_ALL=C
ls -la /bad/
ls: cannot access '/bad/': No such file or directory

ls -la /bad/
ls: cannot access '/bad/': No such file or directory

[JOUBE]

Sorry for the log in german (Connection to: IP:PORT/PFAD/):

Code: Select all

Loading SSH Library
========================
Verbinden mit: IP
IP address: IP:PORT
Key exchange method: curve25519-sha256
Host key method: ssh-ed25519
Encryption method (both directions): aes256-ctr
MAC (message authentication code) method (both directions): hmac-sha2-256-etm@openssh.com
Server-Fingerabdruck:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Unterstützte Authentifizierungsmethoden: publickey,password
Authentifizierung via Kennwort für Benutzer: USER
Sitzung startet... (SFTP)
CONNECT \CONNECTION_NAME
Verzeichnis einlesen: \PFAD\
Verzeichnis nicht geöffnet: Failed opening remote file

The connection then exists, but the TC still jumps back to the SFTP panel (with the saved connections). You then cannot access the server while this connect, you have to disconnect the connection using the button at the top and edit the saved connection in the properties to an existing directory.

But that's not a big thing for me. This should just be a hint for the OP as to why his connection may not be working.