Bug 1835 - sftp should fallback to sshv1 if server doesn't support sshv2
Summary: sftp should fallback to sshv1 if server doesn't support sshv2
Status: CLOSED INVALID
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp (show other bugs)
Version: 5.6p1
Hardware: All All
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-08 21:24 AEDT by jchadima
Modified: 2010-11-08 23:28 AEDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jchadima 2010-11-08 21:24:30 AEDT 
In the case when the server supports protocol 1 only and the client supports 2,1 ssh switches automatically to protocol 1, sftp exits with:
"Protocol major versions differ: 2 vs. 1"
Comment 1 Darren Tucker 2010-11-08 22:12:40 AEDT 
I can't reproduce: as long as the client knows the path to sftp-server it works for me:

$ sftp -v -s /usr/local/libexec/sftp-server -o protocol=2,1 localhost 
OpenSSH_5.6p1, OpenSSL 0.9.7l 28 Sep 2006
[...]
debug1: Remote protocol version 1.5, remote software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_5.6
[...]
sftp> version
SFTP protocol version 3

If the client doesn't have a path for sftp-server and is not given the "-1" option then it doesn't work for a different reason: SSHv1 does not have subsystems so attempting to invoke the "sftp" command via SSHv1 invokes the client rather than the server.

Could you please reproduce with client-side debugging enabled (sftp -vvv)?
Comment 2 jchadima 2010-11-08 23:19:54 AEDT 
Sorry, I've tested old version of openssh.
Comment 3 jchadima 2010-11-08 23:28:00 AEDT 
Caused by the absent -s parameter