Bug 27831 - scp remote remote hangs forever
scp remote remote hangs forever
Status: CLOSED DUPLICATE of bug 103364
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On: 121568
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-15 14:45 EST by Need Real Name
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 04:46:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-02-15 14:45:38 EST
The command
scp user@host1.domain:/file user@host2.domain:/file
asks the password of user@host1.domain
then hangs forever.
In the same time local to remote scp works OK
scp user@host1.domain:/file file
scp file user@host2.domain:/file

The openSSH version is:
rpm -q openssh
openssh-2.3.0p1-4
Comment 1 Pekka Savola 2001-02-24 03:10:32 EST
Are there any messages generated to the logs?  Can you run it with more debugging?

Might this be an access control problem that OpenSSH can't handle gracefully?
Comment 2 Need Real Name 2001-02-24 10:23:28 EST
That original computer, from which it hangs
will be available to me on Monday.
I will try to get the log when scp hangs then.

Here I put nother log where it prints "Aborted by user".
on the same operation.

 scp -v  mal@hostnamehere.com:/home/mal/.bashrc mal@hostnamehere.com:/tmp

It asks first password, and then prints "Aborted by user!"
In server log I have:

Feb 24 10:14:33 central sshd[19592]: Accepted password for mal from 1.2.3.4 port
1021 ssh2
Feb 24 10:14:34 central sshd[19592]: error: channel 0: internal error: we do not
read, but chan_read_failed for istate 8
Feb 24 10:14:34 central sshd[19595]: fatal: Read from socket failed: Broken
pipeFeb 24 10:14:34 central PAM_unix[19592]: (sshd) session closed for user mal
[root@central /root]# 

The client log is below:

[mal@localhost dev]$ scp -v  mal@hostnamehere.com:/home/mal/.bashrc
mal@hostnamehere.com:/tmp
Executing: /usr/bin/ssh -v -x -o'FallBackToRsh no' -n -l mal hostnamehere.com
scp -v /home/mal/.bashrc 'mal@hostnamehere.com:/tmp'
SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: Seeding random number generator
debug: ssh_connect: getuid 500 geteuid 0 anon 0
debug: Connecting to hostnamehere.com [209.10.98.88] port 22.
debug: Allocated local port 1021.
debug: Connection established.
debug: Remote protocol version 2.0, remote software version OpenSSH_2.3.0p1
debug: no match: OpenSSH_2.3.0p1
Enabling compatibility mode for protocol 2.0
debug: Local version string SSH-2.0-OpenSSH_2.3.0p1
debug: Seeding random number generator
debug: send KEXINIT
debug: done
debug: wait KEXINIT
debug: got kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug: got kexinit: ssh-dss
debug: got kexinit:
3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug: got kexinit:
3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160@openssh.com
debug: got kexinit: hmac-sha1,hmac-md5,hmac-ripemd160@openssh.com
debug: got kexinit: none,zlib
debug: got kexinit: none,zlib
debug: got kexinit: 
debug: got kexinit: 
debug: first kex follow: 0 
debug: reserved: 0 
debug: done
debug: kex: server->client 3des-cbc hmac-sha1 none
debug: kex: client->server 3des-cbc hmac-sha1 none
debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST.
debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP.
debug: Got SSH2_MSG_KEX_DH_GEX_GROUP.
debug: bits set: 971/2049
debug: Sending SSH2_MSG_KEX_DH_GEX_INIT.
debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY.
debug: Got SSH2_MSG_KEXDH_REPLY.
debug: Host 'hostnamehere.com' is known and matches the DSA host key.
debug: bits set: 1007/2049
debug: len 55 datafellows 0
debug: dsa_verify: signature correct
debug: Wait SSH2_MSG_NEWKEYS.
debug: GOT SSH2_MSG_NEWKEYS.
debug: send SSH2_MSG_NEWKEYS.
debug: done: send SSH2_MSG_NEWKEYS.
debug: done: KEX2.
debug: send SSH2_MSG_SERVICE_REQUEST
debug: service_accept: ssh-userauth
debug: got SSH2_MSG_SERVICE_ACCEPT
debug: authentications that can continue: publickey,password
debug: next auth method to try is publickey
debug: try pubkey: /home/mal/.ssh/id_dsa
debug: read DSA private key done
debug: sig size 20 20
debug: authentications that can continue: publickey,password
debug: next auth method to try is publickey
debug: next auth method to try is password
mal@hostnamehere.com's password: 
debug: ssh-userauth2 successfull: method password
debug: fd 4 setting O_NONBLOCK
debug: channel 0: new [client-session]
debug: send channel open 0
debug: Entering interactive session.
debug: client_init id 0 arg 0
debug: Sending command: scp -v /home/mal/.bashrc mal@hostnamehere.com:/tmp
debug: channel 0: open confirm rwindow 0 rmax 16384
debug: channel 0: read<=0 rfd 4 len 0
debug: channel 0: read failed
debug: channel 0: input open -> drain
debug: channel 0: close_read
debug: channel 0: input: no drain shortcut
debug: channel 0: ibuf empty
debug: channel 0: input drain -> closed
debug: channel 0: send eof
Executing: program /usr/bin/ssh host hostnamehere.com, user mal, command scp -v
-t /tmp
Aborted by user!

debug: client_input_channel_req: rtype exit-status reply 0
debug: channel 0: rcvd eof
debug: channel 0: output open -> drain
debug: channel 0: rcvd close
debug: channel 0: obuf empty
debug: channel 0: output drain -> closed
debug: channel 0: close_write
debug: channel 0: send close
debug: channel 0: full closed2
debug: channel_free: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1)

select: Bad file descriptor
debug: Transferred: stdin 0, stdout 0, stderr 29 bytes in 0.8 seconds
debug: Bytes per second: stdin 0.0, stdout 0.0, stderr 36.2
debug: Exit status 1
[mal@localhost dev]$ 
Comment 3 Pekka Savola 2001-02-24 10:34:29 EST
I get:

> scp psavola@xxx:/testfile pekkas@yyy.fi:~/temp/
psavola@xxx's password: 
You have no controlling tty.  Cannot read passphrase.
lost connection

Do you have set it so that user@host1 can log on to user@host2 without password (e.g. empty public key authentication)
Comment 4 Need Real Name 2001-02-24 10:46:26 EST
>Do you have set it so that user@host1 can log on to user@host2 without password
(e.g. empty public key authentication)

No, it requires a password. I supposed that ssh will ask the second password.
similar as when I am using scp user@host1.domain:/file file.

Also I have a question how 
scp "remote1" "remote2" should be implemented.
It follows from the log than currently
it implemented in the following way:

send command to remote1 to execute
scp local_file "remote2"

This may be 
1. Security problem if remote1 is compromized.
2. Will not work if remote2 is not available from remote1.
Example: remote1 and remote2 are on different private networks,
client machine has an access to both remote1 and remote2,
but neither remote1 nor remote2 has an access to each other network.

Another way to implement this feature
may be to open from a client machine 2 connections:
to remote1 and to remote2, then just pipe the results from one to another. 

This is basically how
scp user@host1.domain:/file file
scp file user@host2.domain:/file
work. If you pipe the results you do not need a temporary file.
Comment 5 Need Real Name 2001-02-24 10:53:35 EST
In my case same command prints a different message:

scp mal@hostnamehere.com:/home/mal/.bashrc mal@hostnamehere.com:/tmp
mal@hostnamehere.com's password: 
Aborted by user!

select: Bad file descriptor
Comment 6 Pekka Savola 2001-02-24 11:42:28 EST
I seem to be able to reproduce this iff host2 is using Protocol 1 only.
Comment 7 Need Real Name 2001-02-24 11:48:57 EST
All the ssh I use are openssh-2.3.0p1-4 which have
explicitelly set 

Protocol 2

in /etc/ssh/sshd_config
and
        ForwardX11 no
        Protocol 2,1
in /etc/ssh/ssh_config
Comment 8 Ronny Buchmann 2004-10-19 13:40:11 EDT
this is tracked in bug 103364
Comment 9 Tomas Mraz 2005-02-07 04:46:14 EST

*** This bug has been marked as a duplicate of 103364 ***

Note You need to log in before you can comment on or make changes to this bug.