[Bug 88] scp for OpenSSH v3.0.2p1 fails to commercial SSH v3.1.0 server (new -t option to SSH's scp)

[bugzilla-daemon at mindrot.org]

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





------- Additional Comments From brectanu at naxs.net  2002-02-01 06:43 -------
Here is the verbose output of the scp command to send 'testfile' to the remote
host.  I have changed the names to protect the innocent and commented inline
where the problem is.

Here is from SSH v3.1.0 man page on the new '-t' option...

-t or -f
       These options are reserved for  scp1  compatibility
       mode.  If they are used with scp2, it gives them as
       arguments to scp1 to handle the connection.

Here is the trace...

client% scp -v testfile remote.host.some.domain:.
Executing: program /usr/bin/ssh host remote.host.some.domain, user
(unspecified), command scp -v -t .
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 1002 geteuid 1002 anon 1
debug1: Connecting to remote.host.some.domain [nnn.nnn.nnn.nnn] port 22.
debug1: temporarily_use_uid: 1002/203 (e=1002)
debug1: restore_uid
debug1: temporarily_use_uid: 1002/203 (e=1002)
debug1: restore_uid
debug1: Connection established.
debug1: identity file /home/clientuser/.ssh/identity type 0
debug1: identity file /home/clientuser/.ssh/id_rsa type -1
debug1: identity file /home/clientuser/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version 3.1.0 SSH Secure
Shell (non-commercial)
debug1: no match: 3.1.0 SSH Secure Shell (non-commercial)
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: dh_gen_key: priv key bits set: 127/256
debug1: bits set: 479/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'remote.host.some.domain' is known and matches the DSA host key.
debug1: Found key in /home/clientuser/.ssh/known_hosts:9
debug1: bits set: 470/1024
debug1: ssh_dss_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password
debug1: next auth method to try is publickey
debug1: userauth_pubkey_agent: testing agent key /home/clientuser/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 432 lastkey 0x808f690 hint -1
debug1: ssh-userauth2 successful: method publickey
debug1: fd 4 setting O_NONBLOCK
debug1: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0

>>> Here, the 'scp -v -t' command is sent to remote server...

debug1: Sending command: scp -v -t .
debug1: channel 0: open confirm rwindow 100000 rmax 32768
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd close
debug1: channel 0: output open -> drain
debug1: channel 0: input open -> closed
debug1: channel 0: close_read
debug1: channel 0: obuf empty
debug1: channel 0: output drain -> closed
debug1: channel 0: close_write

>>> Here is the error from remote host regarding the '-t' option to scp.
>>> Note we were speaking SSH protocol 2, not 1.  The '-t' option
>>> forced the protocol 1 compatibility mode on the remote side, but
>>> there is not protocol 1 installed (should not need it).

scp: warning: Executing scp1 compatibility. 
scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in
your PATH).

debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead 
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 255
lost connection



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