Bug 20527 (scp_echo)

Umm.. Do you have /usr/bin/scp there on the server? :-)

This error can also happen when users break their .bashrc files (or similar) to
produce output for non-interactive sessions.

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.

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.

*** Bug 90627 has been marked as a duplicate of this bug. ***

I'll eventually look at this.

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.

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.

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.

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.

*** Bug 1296305 has been marked as a duplicate of this bug. ***