Bug 163815 - File not copied to remote machine
File not copied to remote machine
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-07-21 08:31 EDT by Michael McLagan
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-08 11:34:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screen capture showing scp attempt (15.37 KB, image/png)
2005-07-21 08:35 EDT, Michael McLagan
no flags Details

  None (edit)
Description Michael McLagan 2005-07-21 08:31:48 EDT
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 08:35:51 EDT
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 09:14:21 EDT
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 09:16:22 EDT
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 15:14:28 EDT
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 05:32:18 EDT
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 13:52:42 EDT
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 02:39:38 EDT
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 11:34:23 EDT
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.