[Cyberduck-trac] [Cyberduck] #8166: Interoperability with SSH Tectia Server

[Cyberduck]

#8166: Interoperability with SSH Tectia Server
--------------------------------------+---------------------------
 Reporter:  tomihasa                  |         Owner:  I am owner
     Type:  defect                    |        Status:  reopened
 Priority:  high                      |     Milestone:
Component:  sftp                      |       Version:  4.5.1
 Severity:  critical                  |    Resolution:
 Keywords:  listing,directory,failed  |  Architecture:  Intel
 Platform:                            |
--------------------------------------+---------------------------
Changes (by bact):

 * status:  closed => reopened
 * platform:  Mac OS X 10.9 =>
 * resolution:  thirdparty =>


Comment:

 I would like this ticket to be reopened, as it seems to me a CyberDuck
 issue.

 Apparently it seems that the Tectia SSH server creates a handle for the
 OpenDIR operation and gives it to the CyberDuck client.
 When doing ReadDir, Cyberduck client sends back that handle modified to
 the Tectia SSH server, so the Tectia SSH server is not able to fulfill the
 operation.

 The SSH File Transfer Protocol clearly states:
 http://tools.ietf.org/html/draft-ietf-secsh-filexfer-01

  "The SSH_FXP_HANDLE response has the following format: [[BR]]
   uint32     id [[BR]]
   string     handle[[BR]]
  where `id' is the request identifier, and `handle' is an arbitrary string
 that identifies an open file or directory on the server.  The handle is
 opaque to the client; the client MUST NOT attempt to interpret or modify
 it in any way.  The length of the handle string MUST NOT exceed 256 data
 bytes."

 Checking at the SSHJ code (sshj-0.8.1.zip) it seems that the code assumes
 the incoming string is UTF-8, and the code does some conversions that will
 fail if applied against a binary string. Tectia SSH Server sends binary
 strings, so, Cyberduck does some conversion resulting in a modified handle
 when requesting for ReadDir…

 I have taken the liberty to modify the SSHJ code a bit, just by changing
 the type of the “handle” as “byte[]” and using readBytes/writeBytes
 function and it seems to correct the problem.

 I am not sure, though, what version of sshj CyberDuck is using, but I have
 seen a similar behavior.

 To my eyes, Tectia SSH Server works as specified, and Cyberduck is
 violating clearly the protocol. Please, correct me if I am wrong.

-- 
Ticket URL: <https://trac.cyberduck.io/ticket/8166#comment:13>
Cyberduck <http://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows