bugzilla-daemon at mindrot.org
2002-Jul-25 00:14 UTC
[Bug 370] New: scp incompatibility when connecting to Commercial SSH server
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.