[Bug 370] New: scp incompatibility when connecting to Commercial SSH server

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=370

           Summary: scp incompatibility when connecting to Commercial SSH
                    server
           Product: Portable OpenSSH
           Version: -current
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: scp
        AssignedTo: openssh-unix-dev at mindrot.org
        ReportedBy: thewizard75 at hotmail.com


My coworker is attempting to transfer files from one UNIX/Linux system to my 
server using scp.  The server is running:
SSH-2.0-3.2.0 SSH Secure Shell (non-commercial)
Linux hrothgar.math.hmc.edu 2.4.18 #2 SMP Sat Mar 16 10:46:41 PST 2002 i686 
unknown

and he is running:
OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
or
OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
or many more, including new 3.4

The scp client, when invoked with -v, yields: (one example, others similar)
Executing: program /usr/local/bin/ssh host hrothgar.math.hmc.edu, user 
<security>, command scp -v -t <security>
OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
debug1: Reading configuration data /usr/local/etc/ssh_config^M
debug1: Rhosts Authentication disabled, originating port will not be trusted.^M
debug1: restore_uid^M
debug1: ssh_connect: getuid 20358 geteuid 0 anon 1^M
debug1: Connecting to hrothgar.math.hmc.edu [134.173.34.62] port 22.^M
debug1: temporarily_use_uid: 20358/14750 (e=0)^M
debug1: restore_uid^M
debug1: temporarily_use_uid: 20358/14750 (e=0)^M
debug1: restore_uid^M
debug1: Connection established.^M
debug1: read PEM private key done: type DSA^M
debug1: read PEM private key done: type RSA^M
debug1: identity file /home/<security>/.ssh/identity type -1^M
debug1: identity file /home/<security>/.ssh/id_rsa type -1^M
debug1: identity file /home/<security>/.ssh/id_dsa type -1^M
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH Secure 
Shell (non-commercial)^M
debug1: no match: 3.2.0 SSH Secure Shell (non-commercial)^M
Enabling compatibility mode for protocol 2.0^M
debug1: Local version string SSH-2.0-OpenSSH_3.2.3p1^M
debug1: SSH2_MSG_KEXINIT sent^M
debug1: SSH2_MSG_KEXINIT received^M
debug1: kex: server->client aes128-cbc hmac-md5 none^M
debug1: kex: client->server aes128-cbc hmac-md5 none^M
debug1: dh_gen_key: priv key bits set: 111/256^M
debug1: bits set: 492/1024^M
debug1: sending SSH2_MSG_KEXDH_INIT^M
debug1: expecting SSH2_MSG_KEXDH_REPLY^M
debug1: Host 'hrothgar.math.hmc.edu' is known and matches the DSA host key.^M
debug1: Found key in /home/<security>/.ssh/known_hosts:2^M
debug1: bits set: 491/1024^M
debug1: ssh_dss_verify: signature correct^M
debug1: kex_derive_keys^M
debug1: newkeys: mode 1^M
debug1: SSH2_MSG_NEWKEYS sent^M
debug1: waiting for SSH2_MSG_NEWKEYS^M
debug1: newkeys: mode 0^M
debug1: SSH2_MSG_NEWKEYS received^M
debug1: done: ssh_kex2.^M
debug1: send SSH2_MSG_SERVICE_REQUEST^M
debug1: service_accept: ssh-userauth^M
debug1: got SSH2_MSG_SERVICE_ACCEPT^M
debug1: authentications that can continue: publickey,password^M
debug1: next auth method to try is publickey^M
debug1: try privkey: /home/<security>/.ssh/identity^M
debug1: try privkey: /home/<security>/.ssh/id_rsa^M
debug1: try privkey: /home/<security>/.ssh/id_dsa^M
debug1: next auth method to try is password^M
debug1: ssh-userauth2 successful: method password^M
debug1: fd 5 setting O_NONBLOCK^M
debug1: fd 6 setting O_NONBLOCK^M
debug1: fd 7 setting O_NONBLOCK^M
debug1: channel 0: new [client-session]^M
debug1: send channel open 0^M
debug1: Entering interactive session.^M
debug1: ssh_session2_setup: id 0^M
debug1: Sending command: scp -v -t /home/<security>^M
debug1: channel request 0: exec^M
debug1: channel 0: open confirm rwindow 100000 rmax 32768^M
scp: warning: Executing scp1.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0^M
debug1: channel 0: rcvd close^M
debug1: channel 0: output open -> drain^M
debug1: channel 0: close_read^M
debug1: channel 0: input open -> closed^M
scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in 
your PATH).
debug1: channel 0: obuf empty^M
debug1: channel 0: close_write^M
debug1: channel 0: output drain -> closed^M
debug1: channel 0: almost dead^M
debug1: channel 0: gc: notify user^M
debug1: channel 0: gc: user detached^M
debug1: channel 0: send close^M
debug1: channel 0: is dead^M
debug1: channel 0: garbage collecting^M
debug1: channel_free: channel 0: client-session, nchannels 1^M
debug1: fd 0 clearing O_NONBLOCK^M
debug1: fd 1 clearing O_NONBLOCK^M
debug1: fd 2 clearing O_NONBLOCK^M
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds^M
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0^M


Now, I know that the server does not have SSH1 installed for compatibility 
purposes, so OpenSSH's scp (talking to a v.2 server) should really use the sftp 
subsystem to talk to the server (instead of falling back to old scp1 
behavior).  

This is a serious bug/feature of OpenSSH that is precluding many people at my 
institution from using scp to copy from machines with OpenSSH to machines with 
SSH.  Since sftp does not contain commands allowing for the transfer of entire 
directories / multiple files, this is severely crippling the work they are 
trying to do.  Moving from SSH to OpenSSH on the server is not an option, as 
there are other bugs in OpenSSH that would debilitate the server in other 
transactions it makes.  

So is this bug/feature known, and are there any sensible workarounds / 
timetable when scp will attempt to use the subsystem sftp on v. 2 servers 
before falling back to old scp1 behavior?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.