[ 
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Holger Rehn updated SSHD-998:
-----------------------------
    Description: 
Even if using an SftpVersionSelector (e.g. created by 
SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol 
version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. This 
behaviour is hard-coded and may cause problems if the server doesn't correctly 
handle the request/support protocol version 6. One of our customers is using a 
server that initially accepts protocol version 6, but then fails every single 
request by sending invalid data. Actually, the server only correctly supports 
SFTP 3, so this clearly is a bug in the server implementation - but could be 
circumvented quite easily by starting with protocol version 3. Furthermore an 
additional (and actually unnecessary) version renegotiation may be required 
later.

If using an SftpVersionSelector that prefers a certain protocol version other 
than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), an 
additional (and actually unnecessary) network round trip is required for 
protocol version renegotiation. 

 

Please find attached a minimally invasive patch against the official 2.4.0 
source to respect the version(s) accepted by an SftpVersionSelector for 
choosing the initial protocol version.  

  was:
Even if using an SftpVersionSelector (e.g. created by 
SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol 
version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. This 
behaviour is hard-coded and may cause problems if the server doesn't correctly 
handle the request/support protocol version 6. One of our customers is using a 
server that initially accepts protocol version 6, but then fails every single 
request by sending invalid data. Actually, the server only correctly supports 
SFTP 3, so this clearly is a bug in the server implementation - but could be 
circumvented quite easily by starting with protocol version 3. Furthermore an 
additional (and actually unnecessary) version renegotiation may be required 
later.

If using an SftpVersionSelector that prefers a certain protocol version other 
than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), an 
additional (and actually unnecessary) network round trip is required for 
protocol version renegotiation. 

 

Please find attached a minimally invative patch against the official 2.4.0 
source to respect the version(s) accepted by an SftpVersionSelector for 
choosing the initial protocol version.  


> respect SftpVersionSelector when establishing a new connection
> --------------------------------------------------------------
>
>                 Key: SSHD-998
>                 URL: https://issues.apache.org/jira/browse/SSHD-998
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.4.0
>            Reporter: Holger Rehn
>            Priority: Major
>              Labels: features, patch, performance
>         Attachments: patch.diff
>
>
> Even if using an SftpVersionSelector (e.g. created by 
> SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol 
> version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. 
> This behaviour is hard-coded and may cause problems if the server doesn't 
> correctly handle the request/support protocol version 6. One of our customers 
> is using a server that initially accepts protocol version 6, but then fails 
> every single request by sending invalid data. Actually, the server only 
> correctly supports SFTP 3, so this clearly is a bug in the server 
> implementation - but could be circumvented quite easily by starting with 
> protocol version 3. Furthermore an additional (and actually unnecessary) 
> version renegotiation may be required later.
> If using an SftpVersionSelector that prefers a certain protocol version other 
> than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), 
> an additional (and actually unnecessary) network round trip is required for 
> protocol version renegotiation. 
>  
> Please find attached a minimally invasive patch against the official 2.4.0 
> source to respect the version(s) accepted by an SftpVersionSelector for 
> choosing the initial protocol version.  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to