Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163815 - File not copied to remote machine
Summary: File not copied to remote machine
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-21 12:31 UTC by Michael McLagan
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-08 15:34:23 UTC

Attachments (Terms of Use)
screen capture showing scp attempt (deleted)
2005-07-21 12:35 UTC, Michael McLagan
no flags Details

Description Michael McLagan 2005-07-21 12:31:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2

Description of problem:
Upgrading to FC4 has broken the ability to transfer files between machines.  Now, instead of seeing the progress of the copy, it appears that /etc/profile & /etc/bashrc are being run (root login shell is /bin/bash).  No other data is transfered to the remote machine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install FC4 over working FC3 system
2.Start SSHD on remote machine.
3.Try to copy file.

Actual Results:  The file should have appeared on the remote machine.

Expected Results:  Various BASH startup scripts seem to have run -- we have fortune installed and set to run for login shells which is why I believe the scripts are run -- we get a fortune every time we try to copy a file.

Additional info:

The version of openssh used doesn't seem to matter.  I tried to backrev to the FC3 openssh and it has the same result, so I'm thinking the problem lies with BASH or some other configuration but I'm at a loss as to how to track it.

Comment 1 Michael McLagan 2005-07-21 12:35:51 UTC
Created attachment 117019 [details]
screen capture showing scp attempt

This is done with the FC3 BASH, figuring it would correct the problem but it
didn't.  Result is the same across the various version combinations I tried.

Comment 2 Tomas Mraz 2005-07-21 13:14:21 UTC
Are you sure you didn't mess with the bash scripts on the remote machine?
(.bashrc ...)

Have you tried scp-ing to a different machine (even localhost?).

Comment 3 Tomas Mraz 2005-07-21 13:16:22 UTC
The problem lies most probably on the remote machine - the bash scripts (which
are run on the remote machine, so downgrading bash on the local machine is
irrelevant) must not produce any output if run in the noninteractive mode.

Comment 4 Michael McLagan 2005-07-21 19:14:28 UTC
There are 14 machines.  They all have identical /etc/profile and /etc/bashrc
scripts.  There are no custom scripts in /etc/profile.d.  No changes were made
in any of the profile scripts during the upgrade.  I checked the .rpmnew files
to see if anything significant had changed.  None had, so I did not edit our
original scripts.

All of the machines were file transfer (scp) capable before I started the
upgrade on Sunday morning.  By the evening, I was relegated to using ftp to get
files from machine to machine -- NONE would scp files.

I also downgraded bash on multiple machines (I know changing the local copy has
no effect on the remote -- I've been doing this for a while).  I tried
regressing openssh & bash as well.  I compared the /etc/ssh/sshd_config and
/etc/ssh/ssh_config files with the .rpmnew ones and found no significant

None of these resulted in an improvement or I wouldn't have created an open report.

Comment 5 Tomas Mraz 2005-07-22 09:32:18 UTC
Fortune is not a part of Fedora Core 4, so you must first find out where in your
bash scripts it is called or from where the fortune message gets to the ssh output.
This output must be suppressed if the bash running is not an interactive shell.

This means that 'ssh remote-machine bash' must not output anything.

If you resolved the above problem an scp still wouldn't work, please reopen this

Comment 6 Michael McLagan 2005-07-22 17:52:42 UTC
Well, disabling output seems to have helped.  Which then begs the question is
why sshd is now running an interactive shell, or why bash believes that it's
being run interactively now vs FC3 when the exact same fortune script did not
interfere with the copying of files.

Comment 7 Tomas Mraz 2005-07-25 06:39:38 UTC
Are you sure, that bash is now run as interactive shell?
If you downgrade ssh to FC3 version on both server and client machines, does it

Comment 8 Tomas Mraz 2005-09-08 15:34:23 UTC
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received the feedback we
requested, we will assume the problem was not reproduceable or has been fixed in
a later update for this product.

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