SFTP no longer works for some servers

I can no longer connect to some SFTP servers using Directory Opus (11.7 and 11.8, Windows 8.1, 64 bit).

I can still connect to some SFTP sites, but connections to two regularly used devices fail. Both are Synology NAS devices running DSM 5.1, and both are configured with custom port numbers (i.e. not port 22). I am not certain when the problems started, so this may be related to a recent update from DSM 5.0 to 5.1. It does not really seem to be a Synology problem, though, as I can still connect with WinSCP (with SCP fallback disabled) and with Putty (PSFTP). I have tried removing and reinstalling both Directory Opus and PuTTY, and clearing the relevant server fingerprints from the registry, to no effect. I have also tried a quick connection rather than the saved server configuration. It is seemingly not related to network or firewall environments: I've tried both on the same LAN as the device and over the internet, and by IP address and hostname.

FTP logging provides little additional insight for one of the servers. An unspecified error occurs after the start of key exchange, and the connection closes without retries.

[quote]Doing Diffie-Hellman key exchange
SSH: ssh_init: error during SSH connection setup 0
Connection closed[/quote]
This is with FTP logging (and debug) enabled. Enabling the advanced preferences setting for verbose logging (ftp_ssl_verbose) does not seem to log any additional information (I restarted DOpus after changing this setting as recommended).

The other NAS generates a different error:

This same error can be replicated on the other NAS by disabling its setting to accept only hardware-accelerated ciphers. On or off, however, I can connect with WinSCP and PSFTP, but not Directory Opus.

I was under the impression that Directory Opus used the PuTTY code, so it is difficult to understand how it can fail where PuTTY succeeds, or why this has suddenly changed. I would be very grateful for any suggestions on how this might be fixed, or how additional diagnostic details might be logged.

The servers may be requiring an encryption protocol which the code in Opus does not support. If so, we don't have a short-term solution for that, other than configuring the servers to accept the protocols they used to accept when things were still working.

Thank you for your reply.

The NAS provides few configuration options for SFTP connections aside from the 'accept only hardware-accelerated ciphers' option I mentioned before. This is a recent addition and not well documented by Synology; but it is not available for some models, and as noted above, DOpus does not work whether this is enabled or not. I have no reason to believe there have been other recent changes in their implementation of the protocol: there is nothing pertinent in the release notes.

Whilst the second error message regarding cipher support is clear and explicit, that only applies to one NAS (or configuration setting). In the other case, 'error during SSH connection setup 0' is very vague and presumably relates to a different issue. Under what circumstances should this be issued? Is there any way to obtain diagnostic data? The built-in logging (including debug and verbose options) do not seem to provide anything informative in this case.

It is still possible, of course, that this message also relates to encryption protocols; although I would find it surprising. It is not generally necessary to make special server-side arrangements to support a specific FTP client. Do you have any reason to believe this might be the case, and have there been other reports of this issue? When paying extra for FTP support, one might anticipate support of the methods available free of charge in PuTTY and WinSCP (and especially if there is a common code base!). There does not seem to be any documentation of what protocols DOpus supports: if you have any information about this, that might be useful for further investigation.

I will try some tests from another system, to eliminate Windows configuration issues. If all else fails, if I created an unprivileged account to log in to, would you be willing/able to try and connect from DOpus in a debugging environment to try and diagnose the issue? (Obviously I would prefer not to communicate the details in a public forum).

If you'd like to do that, please email the details to greg @ gpsoft . com . au

I have now reproduced this behaviour on another system (Windows 7).

I also have more information about the issue. The Synology NAS is using OpenSSH 6.6p2. The 'hardware accelerated ciphers' are aes128-cbc, 3des-cbc, aes192-cbc and aes256-cbc, which are not in the list DOpus reports as available in the log error message. At present, it is therefore probably necessary for Synology users to disable this option. Doing so is not, however, sufficient to get DOpus to be connect. As of OpenSSH 6.7, CBC ciphers are disabled by default as unsafe anyway, so this is probably not a bad idea (at the expense of sub-optimal performance).

I have verified that the connection successfully established by WinSCP is using Diffie-Hellman group exchange, with hash SHA-256, and AES-256 SDCTR encryption. WinSCP negotiates SFTP version 3. The cipher seems to be the same as the aes256-ctr DOpus reports being available, so it is not at all clear why this is a problem. DOpus does not make clear what flavour of Diffie-Hillman key exchange it is using, but there is again no obvious sign that this should be problematic.

OpenSSH since 6.4 has apparently had curve25519-sha256@libssh.org as a default, but with a bug in 6.5 and 6.6 causing some such connections to fail; but that clearly has not prevented negotiating something else with WinSCP. Since OpenSSH 6.4, proprietary clients using 'a weaker key exchange hash calculation' have been rejected, and the size of the Diffie-Hellman groups requested have been increased. Perhaps this is something to do with it.

Is there any way to control the ciphers or key exchange mechanisms attempted by DOpus (in advanced preferences, registry settings, command line files, configuration files etc.)? What limits are imposed for KEX hash, group size etc.?

None of those things are currently configurable in Opus, sorry.

Thank you for the prompt replies. I might (possibly!) be getting closer to understanding the problem, but we are not really getting any closer to a solution! I will create a testing account and send the details by e-mail as discussed before, so hopefully this can be diagnosed in more detail.

I really hope this will taken seriously and a solution can be found fairly promptly. This seems unlikely to be unique to Synology, and if it is related to more restrictive security policies (either by default in recent versions of OpenSSH or by administrators in response to the recent security issues), the problem is likely to become more prevalent in future. It is unrealistic to expect every server administrator to modify their configuration to support this one FTP client, so DOpus really needs to keep pace.

Have a look here: Cannot connect via sftp

DOpus requires AES256-CDC, and many current builds of OpenSSH have that code stripped out. The documentation 'trick' for re-enabling it via the settings is not possible in those situations.

Thank you: for some reason I missed the earlier thread when I posted. The problem is now well understood - DOpus is using a rather antique version of the PuTTY code - so we just need to wait for them to fix it.

New or upgrading customers considering paying extra for the Advanced FTP support should first test all servers to which they intend to connect: perhaps checking the reported OpenSSH version, or attempting a connection with a PuTTY version of similar vintage, say 0.60. (Obviously in the latter case the release should be found from a trusted source and removed after testing.)

In my opinion, the website should be updated as a matter of urgency - especially http://www.gpsoft.com.au/DScripts/english_optional_features.html and the pop-up box on the purchasing page that refers to it - to avoid misleading customers. The present content gives customers every reason to believe that they should have the same compatibility provided by PuTTY.

While we greatly appreciate the sentiment you expressed above, the current major version of Directory Opus has the capability for Advanced Secure FTP using secure FTP for SSL and FTP over SSH according to the versions available at the time this major version of Opus was developed. The SSL versions are current (post heartbeat) but the SSH versions are based on an older version of Putty available at the time and which works happily for many sites supporting the full range of SSH protocols, but not some if the admin has imposed tighter security requirements using only the very latest protocols.

The Advanced Secure FTP option is an add- on to the main Opus program for a small extra fee and is available for a full test and evaluation before a user purchases the add-on.

As with all such products, it is up to the user to decide whether the product is suitable for their purposes.

As in this case, and with all such issues with Opus, if an end user has an issue, either during the evaluation period or during normal usage, we are happy to discuss and evaluate the issues direct with the end user.

I just installed Synology DS211j at home and ran to the same problem. Evaluating Directory Opus 11.0 x64 under Windows 7, DS211j using DSM 5.1-5021 Update 2.

With default sshd configuration I got the same error message mentioned above:

Opening Connection 192.168.1.2:22
Server version: SSH-2.0-OpenSSH_6.6p2-hpn14v4
We claim version: SSH-2.0-PuTTY-FZ-Local: Sep 16 2014 11:09:50
Using SSH protocol version 2
Couldn't agree a client-to-server cipher (available: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com)
SSH: Fatal: Couldn't agree a client-to-server cipher (available: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com)
Connection closed

Then I played with Ciphers in sshd_config and adding only aes256-ctr there gave me a similar error:

Couldn't agree a client-to-server cipher (available: aes256-ctr)

When I added also aes256-cbc, which is supported by Directory Opus, then the following error appeared:

Opening Connection 192.168.1.2:22
Server version: SSH-2.0-OpenSSH_6.6p2-hpn14v4
We claim version: SSH-2.0-PuTTY-FZ-Local: Sep 16 2014 11:09:50
Using SSH protocol version 2
Doing Diffie-Hellman key exchange
SSH: ssh_init: error during SSH connection setup 0
Connection closed

Have I understood it correctly now, that OpenSSH v6.6 does not support aes256-cbc any more and Directory Opus does not support aes256-ctr yet, as in my example here? So there are no common ciphers that will work?

I'm sorry, but the responses from Leo and Greg have left me with an impression that this is something they don't want to acknowledge as a problem and they are not even planning do deal with it any time soon, although judging by different forum posts it seems to be quite an old issue already. But what is a solution then? Use WinSCP instead? Somehow downgrade OpenSSH on my Synology NAS? Something else?

I only wanted to let you know that here is one more person having similar problems and I'm sure there are more and more as time goes by and Directory Opus' SSH implementation stays put. I'm hoping you'll find the resources to get it up to date again. Thank you!

Hi,

using sftp in dopus is one of my favorite features so it is really annying that i cant use it anymore on various sftp-sites, which sadly renders this feature quite useless for me...

Since the previous poster pretty much said everything there is to say about this topic,
I want add my name to the list of people having the same problem.

Would be great if you fix this issue,
Thanks!

Not much to add. Just that I'm in the same position with my Synology.
And would appreciate a solution.

Just to let you know we're working on this, hopefully we will have a solution soon.

Thank you for your reply, jon.
I'm also patiently waiting for a solution.

Happy to hear that!
I have installed a new firmware to one of my QNAP NAS with the latest available firmware 4.1.2 and then the problema appeared to me.
I use a lot the SFTP conection so, happy to hear you're working on it.

Thank you in advance!

The latest beta is based on an updated version of Putty which will hopefully allow you to connect to these servers again.

The code we use is heavily customised which is why it's a major effort to update it (Putty is not built to be a simple drop-in library unfortunately). It may also mean unexpected bugs or other issues sneak in - so please try the beta and let us know how it goes.

Thanks - the beta did the trick - I can now use SFTP again! (Box with debian Jessie was causing me trouble)

/niklas

Big problem with the last beta 5. It’s not possible to connect to my SFTP site.
With beta 3 no problem, with beta 5 impossible (I never install beta 4).

BETA 3

Ouverture de connexion… Server version: SSH-2.0-OpenSSH_4.4 We claim version: SSH-2.0-PuTTY-FZ-Local: Jan 16 2015 11:40:20 Using SSH protocol version 2 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange Host key fingerprint is: ssh-rsa 2048 8e:39:f1:aa:44:3f:d1:ed:28:35:90:6a:6e:43:39:f4 Initialised AES-256 client->server encryption Initialised AES-256 server->client encryption Keyboard-interactive authentication refused Sent password Access granted Opened channel for session Started a shell/command

BETA 5

Opening Connection… Server version: SSH-2.0-OpenSSH_4.4 Using SSH protocol version 2 We claim version: SSH-2.0-PuTTY_Local:_Feb__6_2015_12:07:52 Server supports delayed compression; will try this later Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange with hash SHA-256 Host key fingerprint is: ssh-rsa 2048 8e:39:f1:aa:44:3f:d1:ed:28:35:90:6a:6e:43:39:f4 Initialised AES-256 SDCTR client->server encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised AES-256 SDCTR server->client encryption Initialised HMAC-SHA1 server->client MAC algorithm Connection closed

Working here with SFTP, tested on 2 hosters (for German people: Strato and 1&1) and also on a Synology NAS. Upload also reaches max. speed.