Bug 20527 (scp_echo) - scp breaks when there's an echo command in /etc/bashrc
Summary: scp breaks when there's an echo command in /etc/bashrc
Keywords:
Status: CLOSED WONTFIX
Alias: scp_echo
Product: Fedora
Classification: Fedora
Component: openssh
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
URL:
Whiteboard:
: 90627 1296305 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-11-08 16:42 UTC by james
Modified: 2019-09-12 07:38 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-03-18 09:59:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description james 2000-11-08 16:42:14 UTC
This problem also reported to OpenSSH by another admin.   No solution
found, though there was a comment about the default path.

You can look at
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=96925628720406&w=2
and follow the thread.

Comment 1 Pekka Savola 2000-11-11 14:54:02 UTC
Umm.. Do you have /usr/bin/scp there on the server? :-)



Comment 2 Damien Miller 2000-12-15 02:48:06 UTC
This error can also happen when users break their .bashrc files (or similar) to
produce output for non-interactive sessions.

Comment 3 james 2000-12-15 18:42:42 UTC
Where this problem is caused by text being returned from the remote shell, I
can suggest three approaches to solving the problem.

First, note for instance the man page for Bash-2.04:

       INVOCATION
       ...
       Bash  attempts  to  determine  when it is being run by the
       remote shell daemon, usually rshd.  If bash determines  it
       is  being run by rshd, it reads and executes commands from
       ~/.bashrc, if that file exists and is readable.   It  will
       not  do  this  if invoked as sh. ...

So, though normally bash would not run ~/.bashrc for a non-interactive
shell, with ssh it does so anyway.

1) Look very carefully at ~/.bashrc (and any scripts or programs called by
   ~/.bashrc) and remove or modify (-q for "quiet" perhaps) any commands
   which are generating output.

2) Where 1) is impractical (say ~/.bashrc must provide progress or status
   messages), hack bash to run a different script ("~/bash_rsh" perhaps)
   when bash is invoked by ssh.  Look in bash-2.04/shell.c:

 --- shell.c.stock       Fri Dec 15 11:00:02 2000
 +++ shell.c     Fri Dec 15 11:02:51 2000
 @@ -874,7 +874,7 @@
           maybe_execute_file (SYS_BASHRC, 1);
  #  endif
  #endif
 -         maybe_execute_file (bashrc_file, 1);
 +         maybe_execute_file ("~/.bash_rsh", 1);
           return;
         }
      }

   Next, place ssh specific commands into ~/.bash_rsh.  for instance:
    export PATH=/usr:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:~/bin
   to access executable files in /usr/X11R6/bin/.

3) The non-robust behavior of scp in response to remote shell generated
   text is unfortunate and unnecessary.  You may want to write to the
   OpenSSH Developers <openssh-unix-dev> and extol the virtues
   of a more robust scp.  There has already been one suggestion to modify
   scp ("Richard E. Silverman" <slade>) to wait for an scp "magic
   cookie" in a manner similar to the way sendmail waits for HELO.
   Alternatively, here is an opportunity to contribute to open source
   software and learn more about the ssh protocol.



Comment 4 Tomas Mraz 2005-02-02 16:26:21 UTC
It's still true as of openssh-3.9p1 (FC3).

Please report this (esp. comment 3) to upstream bugzilla if not
already reported here.

This needs to be fixed upstream first.

Comment 5 Tomas Mraz 2005-02-04 13:53:05 UTC
*** Bug 90627 has been marked as a duplicate of this bug. ***

Comment 6 Tomas Mraz 2005-02-04 13:55:09 UTC
I'll eventually look at this.

Comment 7 Tomas Mraz 2005-03-18 09:59:10 UTC
This won't be accepted by upstream and as such it doesn't make sense to fix.
The possible workaround which is planned for upstream is to add a new sftp
client interface equivalent to scp.


Comment 8 Rory Murphy 2011-11-08 18:10:28 UTC
When looking for a solution for this issue myself I found this bug, and found a solution.

My situation was that when someone logged in I wanted the user to have some system data outputted, this broke SCP.

I ended up wrapping the output into a if statement. 

if [ "$SSH_TTY" ]
then
          # Put output here
          free
          df -h
fi

Anyway, this works for me.

Comment 9 Jay Hilliard 2015-07-23 04:00:21 UTC
Why was this closed? Is it a client bug?

I use scp on Yosemite 10.10.4 to/from RHEL7.1
scp give me a silent failure.
In my .bashrc on RHEL7 I added this test (for interactive shell) to restrict the echo

[[ $- == *i* ]] && echo 'Message'

Now I can scp to/from this Red Hat Linux 7.1 system.

Comment 10 Tomas Mraz 2015-07-23 08:42:01 UTC
There is no way to allow for this issue to be reasonably fixed. The SCP protocol and implementation is regarded as legacy by upstream and will not be modified to allow for fixing this problem. There is a simple workaround - just do not echo anything on noninteractive shell.

Comment 11 Steve Dickson 2016-01-11 17:19:29 UTC
*** Bug 1296305 has been marked as a duplicate of this bug. ***


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