Accessing Savannah (which does not support SSH protocol 2), the following fails: sftp USERNAME@savannah.nongnu.org sftp -F ~/.ssh/config USERNAME@savannah.nongnu.org even when ~/.ssh/config contains the snippet: Host savannah.gnu.org Protocol 1 whereas "sftp -1 USERNAME@savannah.nongnu.org" succeeds. This implies that the "Protocol 1" directive is not being honored by sftp. This is a real problem for folks using software which calls sftp without permitting the user to specify command line arguments. (tla, a revision control system with support for hosting repositories on sftp servers, is one such piece of software).
> Accessing Savannah (which does not support SSH protocol 2), the following fails: > sftp USERNAME@savannah.nongnu.org[1] > even when ~/.ssh/config contains the snippet: > Host savannah.gnu.org[2] You realise that [1] and [2] are not the same host, right?
Err, yes, that's a typo on my part (hand-entered the ~/.ssh/config snippet rather than cut&pasting it). The actual ~/.ssh/config file does indeed reference savannah.nongnu.org. Further, this observation has been backed up by a few other tla users (it's come up on our IRC channel; see #arch on freenode), so it would seem unlikely to just be user error.
Can't reproduce with 3.7.1p2. In ~/.ssh/config: Host localhost-test Hostname localhost Protocol 1 $ scp -v localhost-test:/tmp/tmp1 /tmp/tmp2 Executing: program /usr/local/bin/ssh host localhost-test, user (unspecified), command scp -v -f /tmp/tmp1 [snip] debug1: match: OpenSSH_3.7.1p2 pat OpenSSH* Protocol major versions differ: 1 vs. 2 debug1: Calling cleanup 0x8060294(0x0) lost connection (The server is configured to allow Protocol 2 only, which is why this fails). Do you have 2 versions of ssh installed? Do you get the same result with 3.7.1p2?
Er, hang on. That's sftp, which normally uses a SSH2 channel. Is that even supposed to work over SSH1?
You are correct. sftp directly does a 'addargs(&args, "-oProtocol %d", sshvar)' where sshvar is *ALWAYS* a value of 2 unless you use -1 as a commandline argument. Since sftp never parses the .ssh/config nor ssh_config directly it has no clue that you want to default to protocol 1. Only the underlying ssh connection reads those files (same with scp). Since sftp uses a 'subsystem' and was created for protocol 2.. The -1 support is really a hack to allow it to work. As a result, I think I'm going to tag this as 'Enhancement'.
Created attachment 483 [details] Don't set "-oProtocol" in sftp.c except for SSHv1 I suspect that the forcing of protocol 2 dates back to when ssh(1) defaulted to Protocol 1. Since ssh now defaults to Protocol 2, we could change sftp.c to only add -oProtocol for the "-1" option, like so and let ssh figure it out otherwise. Perhaps sftp needs a "-2" option to correspond to "-1"?
Er, please ignore the second part (changes to regress/banner.sh) in patch id #483. It's harmless but it's not related to this bug.
Comment on attachment 483 [details] Don't set "-oProtocol" in sftp.c except for SSHv1 On second thought, ignore the whole patch, it's just wrong (thanks bal).
Created attachment 484 [details] Rough quicky patch This is an extremely rough and quick patch that allows it. Some code should be moved around to make a better version, but this will give an idea on what is involved.
BTW you do need to modify the makefile to change the 'sftp' target to ass in 'readconf.o' (or readconf.c for OpenBSD). The patch is against OpenBSD tree, but should hopefully apply clean on portable.
sftp should default to protocol 2, as the draft-ietf-secsh-filexfer (sftp) protocol is not specified for protocol v.1. It will only work against OpenSSH servers. Even egainst these it is not likely to be completely reliable as the client has to launch sftp-server by pathname. I agree that the current behaviour is confusing, but changing it may break many working setups.
i don't think that sftp should ever read the ssh config file.
Markus: Why not? From an end-user perspective, it's quite counterintuitive; there've been at least three independant arch/tla users who've noticed that behaviour and found it suprising. Do you propose a separate sftp config file?
The problem is as such: Protocol 1 Protocol 2 work fine if you read the .config or ssh_config with the attached patch, but if you do: Protocol 1,2 and the server only supports Protocol 2 it will fail because the sftp client can't change gears once it starts the ssh session. The only good way of handling this would be to teach -s option to support it's own name space. IE: ssh -s sftp site.com /path/to/sftp-server That would allow ssh to pick a protocol and attach to it correctly, and allow sftp to be blissfully ignorant of the underlying protocol. But I don't see that happening in the future since sftp over protocol 1 is pretty much a hack and unless the client knows the extact location of sftp- server or the sftp-server is in the path and the client does not /set/the/starting/path/. It will fail giving even odder error messages (see the whole 'scp not in path' threads on openssh-unix-dev@ mailinglist).
WONTFIX: reading the config file is insufficient, as you don't really know what version protocol the server speaks until after banner exchange. We are certainly not going to add support to poke the negotiated protocol up to sftp just to support the nearly moribund protocol 1. Sorry.
Mass update RESOLVED->CLOSED after release of openssh-5.1