Bug 1259925 - scp between Fedora Rawhide and Fedora 22 does not work with strange output
Summary: scp between Fedora Rawhide and Fedora 22 does not work with strange output
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Petr Lautrbach
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-03 20:01 UTC by Randy Barlow
Modified: 2015-09-09 21:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-09 21:06:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Randy Barlow 2015-09-03 20:01:27 UTC
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
openssh-clients-7.1p1-1.fc24.x86_64

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 10.3.113.209:~/.bashrc .                                                     
           /:-------------:\          rbarlow.com
% echo $?
1

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 10.3.113.209 ([10.3.113.209]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00 want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -f ~/.bashrc
Sink:            /:-------------:\          rbarlow.com
           /:-------------:\          rbarlow.com
[rbarlow@ohm]~% debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow 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 18:45:35 UTC
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 15:45:23 UTC
I was trying to introduce the behaviour you described but without any success:

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

> /:-------------:\
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 21:06:07 UTC
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.