I just used the DO FTP client to connect to a few remote servers to QA a fix. I could see subfolders fine one second, and in the next they completely vanished. Now I can only see folders and files for one connection, the others are blank. I downloaded and tried this with CyberDuck FTP, and it worked fine. Something is different in DO. I changed nothing, and use FTP all the time. Any thoughts?
Oh, and in the logs I see this:
RecvList() - [0] No Error
** WSA returns ERROR **
550 The client and server cannot communicate, because they do not possess a common algorithm.
No idea what that means. Thanks!
Are you using SFTP and quite an old version of Opus?
Version 12 of DO. I have not touched my settings in months. This is very sudden. My connections work fine in CyberDuck, exact same credentials. Secure TLS Explicit. Port 21. Thanks!
Possibly something on the server side changed, or firewall/antivirus changed and is treating Opus or the connection it is making differently
The error message sounds like it cannot agree an encryption protocol for both sides to use.
Can you show us the full logs (with anything private blanked out) of Opus and the other program to compare what both are doing?
Thanks, Leo. Here is one that worked:
211-Extended features supported:
LANG EN*
UTF8
AUTH TLS;TLS-C;SSL;TLS-P;
PBSZ
PROT C;P;
CCC
HOST
SIZE
MDTM
REST STREAM
211 END
USER XXXXXXX
331 Password required
PASS XXXXXXXXX
230 User logged in.
OPTS UTF8 ON
200 OPTS UTF8 command successful - UTF8 encoding now ON.
SYST
215 Windows_NT
CWD /
250 CWD command successful.
TYPE A
200 Type set to A.
PASV
227 Entering Passive Mode (198,107,132,38,81,61).
LIST -a
125 Data connection already open; Transfer starting.
12-28-16 07:07PM
01-20-17 05:51PM
09-27-17 04:02AM
07-31-17 04:42PM
10-30-14 11:41AM 265823033 Export.rar
09-19-17 08:06PM
226 Transfer complete.
Here is a broken one (but I kid you not, this worked for a few seconds this morning):
Opening Connection ftp-XXXXXXXX.com:21
220 Microsoft FTP Service
234 AUTH command ok. Expecting TLS Negotiation.
331 Password required
230 User logged in.
200 PBSZ command successful.
200 PROT command successful.
215 Windows_NT
211-Extended features supported:
LANG EN*
UTF8
AUTH TLS;TLS-C;SSL;TLS-P;
PBSZ
PROT C;P;
CCC
HOST
SIZE
MDTM
REST STREAM
211 END
200 OPTS UTF8 command successful - UTF8 encoding now ON.
200 Type set to A.
257 "/" is current directory.
250 CWD command successful.
257 "/" is current directory.
227 Entering Passive Mode (10,202,19,21,109,127).
125 Data connection already open; Transfer starting.
550 The client and server cannot communicate, because they do not possess a common algorithm.
RecvList() - [0] No Error
** WSA returns ERROR **
227 Entering Passive Mode (10,202,19,21,109,131).
Just got this from the server host I am trying to punch into with DO. Their FTP service was busted, but is fixed now. They are not referring to a fix that allows me to see things in DO.
"The issue has been resolved by implementing new FTP solution to serve FTP/FTPS traffic and allowing to decrease the amount of traffic on old FTP servers (handling SFTP) to minimum. And yes there is a change in back-end servers for FTP and FTPS connections. It is now hosted on Microsoft IIS servers rather than Serv-U FTP software we used before. This was due to huge issue in Serv-U FTP code which was affecting all clients and ability to use FTP globally
"Also, may your FTP client is old/out of date because we use latest IIS 8.5 and support Microsoft recommended algorithms."
The support team for the product I am trying to punch into via FTP is telling me the following, which does not seem to apply to anything I can control with DO:
I recommend you to enable the enable TLS 1.2. TLS 1.2 has improvements over previous versions of the TLS and SSL protocol which will improve your level of security. TLS has been improved to version 1.2 in order to support:
Hash negotiation. The client and server can negotiate any hash algorithm to be used as a built-in feature, and the default cipher pair MD5/SHA-1 has been replaced with SHA-256.
Certificate hash or signature control. You can configure the certificate requester to accept only specified hash or signature algorithm pairs in the certification path.
Suite B–compliant cipher suites. Two cipher suites have been added so that the use of TLS can be Suite B compliant:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
I am still baffled about happened and why this broke.
Is there any way we could get a test login for the server?
It may just be a case of changing some SSL parameters on our side to make things work with their side, but it's hard to be sure without being able to try a few things out.
If it is possible to arrange a test login, please send it via private message, or email (crashdumps@gpsoft.com.au will reach both Jon and myself).