Bug 1259925 - scp between Fedora Rawhide and Fedora 22 does not work with strange output
scp between Fedora Rawhide and Fedora 22 does not work with strange output
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-09-03 16:01 EDT by Randy Barlow
Modified: 2015-09-09 17:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-09 17:06:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Randy Barlow 2015-09-03 16:01:27 EDT
Description of problem:
I am unable to scp a file from my Fedora 22 machine to my Fedora Rawhide machine (scp running on the Rawhide machine).

Version-Release number of selected component (if applicable):
% rpm -q openssh-clients

How reproducible:
Every time.

Steps to Reproduce:
1. Install an F22 machine and a Rawhide machine.
2. Enable sshd on the F22 machine.
3. On Rawhide: scp f22.example.com:~/.bashrc .

Actual results:
% scp .                                                     
           /:-------------:\          rbarlow@host.example.com
% echo $?

Also, the file is not transferred.

Expected results:
The file should be transferred.

Additional info:
I tried running this with the -v flag, and it is not obvious to me what the issue is. I've trimmed out the authentication bits at the beginning:

Authenticated to ([]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -f ~/.bashrc
Sink:            /:-------------:\          rbarlow@host.example.com
           /:-------------:\          rbarlow@host.example.com
[rbarlow@ohm]~% debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2876, received 4252 bytes, in 1.7 seconds
Bytes per second: sent 1676.3, received 2478.3
debug1: Exit status 1

Also, it seems that there isn't a component for openssh-clients, so I filed this under the openssh component instead.
Comment 1 Randy Barlow 2015-09-04 14:45:35 EDT
Two more data points:

0) I am able to scp in the reverse direction. I.e., I can initiate the scp from the Fedora 22 machine into the Fedora Rawhide machine and push a file.

1) I am able to initiate an scp from Rawhide and pull a file from a Gentoo system. Perhaps this indicates some incompatibility that only exists between Rawhide and 22? That seems unlikely, however. I wish I got more output with the -v flag!
Comment 2 Jakub Jelen 2015-09-07 11:45:23 EDT
I was trying to introduce the behaviour you described but without any success:

[root@localhost tmp]# scp .
.bashrc                                         100%  176     0.2KB/s   00:00    
[root@localhost tmp]# echo $?

> /:-------------:\
this is actual string you see in your terminal during transfer?

Last change that was in scp program was related to progress-meter in openssh-6.9p1-4 + 0.9.3-6, which went into Fedora 22. Can you try the same with -q option to disable progress-meter?

What do you have in your sshd_config on Fedora 22? Which type of authentication are you using? Normal ssh sessions works fine?
Comment 3 Randy Barlow 2015-09-09 17:06:07 EDT
Yes, it actually printed a line with /:-------------:\ in colorful text. Strange, right?

I am now unable to reproduce this problem (perhaps due to an update in some dependency?) Sorry for the noise!

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