Can't connect to a SFTP server

Help & Support
6

There are some public test SFTP servers here: https://www.sftp.net/public-online-sftp-servers

It would be interesting to see if Opus can connect to those. If it can't, it might be a firewall issue, with Opus being blocked from SFTP access but other software allowed through.

(Assuming the other software can access the test servers and Opus can't. If nothing can access the test servers, it could be that you can only access SFTP servers on your LAN and not on the internet, which makes testing if the problem is server-specific harder.)

7

I'm able to connect to all of those servers. One of them doesn't have any public username/password, but I can connect fine to that too. None of them allows me to setup key file authentication.

I'm quite sure it's not a firewall issue as I never did any special configuration for FileZilla or WinSCP. I am also able to connect via WSL1.

Also, I've been connecting to my office server from home via internet and not on LAN/VPN.

8

@Leo Can you provide me a list of supported standards related to SFTP? I mean standards like hostkey algorithms, key exchange algos, encryption algos, etc. I can check with our admin if any of those is incompatible. Also, is there were a way to print some more debug information from Directory Opus while connecting?

9

I ran filezilla with debug on. Here is some info that may be important:

Trace:	Doing ECDH key exchange with curve Curve25519 and hash SHA-256 (unaccelerated)
Trace:	Server also has ssh-rsa host key, but we don't know it
Trace:	Host key fingerprint is:
Trace:	ecdsa-sha2-nistp256 256.....

I noticed in another thread that Curve25519 may not be supported yet?

10

I had the same problem, Curve25519 is not supported. The SSH code used in DOPUS is quite old.

11

Correct, it's not supported in Opus yet. You'd normally get a better error message than the one you were seeing, so there may be something else wrong, but if you need Curve25519 then it would not currently work either way.

We plan to update the algorithms SFTP supports, but don't have a timeframe yet, as there is lots of other work to finish first.

12

Well.. if there is some way to help you figure out what else may be wrong, please let me know. I'll see if I can connect using a supported algorithm.

13

I had a debugging session with the admin and also used wireshark on my system. This problem seems to be different from KEX limitations. Handshaking didn't even reach KEX. In wireshark, I see the following communication with the server IP:

client -> server : [SYN]
server -> client : [SYN, ACK]
client -> server : [ACK]
... TCP Keep-alive messages from server to client and client to server for a couple of minutes ...
server -> client : [FIN, ACK]
client -> server : [ACK]
client -> server : [FIN, ACK]
server -> client : [ACK]

In filezilla, at connection start, I see the following instead:

client -> server : [SYN]
server -> client : [SYN, ACK]
client -> server : [ACK]
client -> server : [PSH, ACK] : Data: SSH-2.0-FileZilla_3.50.0
server -> client : [ACK]
server -> client : [PSH, ACK] : Data: SSH-2.0-ProFTPD 1.3.1. Authorized uses only. All activity may be monitored and reported.
server -> client : [PSH, ACK] : Data: qcurve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1ssh-rsa,ecdsa-sha2-nistp256laes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctrlaes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctrBhmac-sha2-256-etm@openssh.com,hmac-sha2-256,hmac-sha1,hmac-sha1-96Bhmac-sha2-256-etm...
client -> server : [ACK]
...

Also, on the server side, it either receives nothing for the whole time (as indicated by server logs showing an i/o timeout when dopus aborts after a while). Based on our debugging, it seems that Directory Opus isn't even starting the handshake as it's supposed to.

14

@Leo It may be worth debugging the connection process for SFTP over SSL, especially with private key files. A bug may have been introduced recently.

15

Maybe DOpus is waiting for the FTP server banner first while the server is waiting for the client banner first before sending KEX information. I hope this debugging effort helps. :slight_smile:

16

We use that all the time without any issues. It's probably something specific to the server, or to the network or something else between the two (firewall software/hardware, etc.). That would make it impossible for us to reproduce and debug, unfortunately.

The SSH code is currently based on PuTTY. Are you able to connect to the same server from the same machine using that?

17

Yes. I can. I connected with PuTTY too. I get a login prompt asking user name and after entering the user name, it authenticates successfully through my public key. Then, the server refuses to start a shell/command after successful login because it's SFTP-only.

The issue I'm seeing happens only with DOpus. No other client demonstrates any problem.

18

Turning on the Debug logging option for the site in Opus may add some additional information. (Detail in the FTP Doesn't Work FAQ.)

But I would also verify that you can connect using other algorithms first, else the whole thing is moot either way. (To clarify: The Putty version you're using may support more/newer algorithms than Opus.)

19

I have "debug" enabled in the "Display" section for the site configuration. The displayed information is the same as in my first post.

Based on the server's logs and wireshark logs on my system, it seems that DOpus doesn't even reach the point where it should get the list of supported algorithms. As I described in the post above, server seems to expect the client to send a banner first before it sends its own banner. However, it seems that DOpus may be waiting for a banner from server instead.

20

@Leo If needed, I can share our server's address via a private message for you to test the connection sequence.

21

If the server is not on a private LAN or VPN, and can be accessed via the public internet, then we'd be happy to try connecting to it.

22

@Leo I have sent the server address as a private/direct message. Please let me know if I can help in any way.

23

I've spent a while trying to debug this this morning.

Opus doesn't seem to get any data back from the server at all, as far as I can tell.

I can't find anything to support the idea that a client should send a banner to the server. Other servers don't seem to expect this either.

I did find a post saying the banner from the server is sent encrypted, after encryption and key exchange has been negotiated. So one possibility is that the two sides cannot agree an encryption protocol to get that far. But you usually get a proper error message when that happens. Maybe other servers fall back on one of the disabled encryption protocols just to send a proper failure message (which doesn't really need strong encryption), but this server is configured so it won't do that (e.g. the other encryption methods are not only turned off, but completely removed from its code). That's just a guess, though, as I'm not an expert on SSH/SFTP at this low a level.

I'd expect things to work when we switch SFTP libraries in future, which is something we plan to do (for a few different reasons; better performance on top of newer algorithms). I can't say when that will happen, though.

24

Looking at Wireshark log, I see that the messages like banners aren't encrypted. The messages I mentioned in the log are in plain text. The log for Filezilla shows that Filezilla sent its banner first ("SSH-2.0-FileZilla_3.50.0"). After that, the server responded with its own banner ("SSH-2.0-ProFTPD 1.3.1. Authorized uses only. All...") immediately followed by the list of supported algorithms ("qcurve25519-sha256@libssh.org,ecdh-sha2-nistp256..."). I'm not familiar with SFTP protocol either, but it's just an observation from the monitored traffic.

25

Looking at SSH connection/handshake process, I see that this may be a standard step in SSH connection process.