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
and follow the thread.
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:
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);
- maybe_execute_file (bashrc_file, 1);
+ maybe_execute_file ("~/.bash_rsh", 1);
Next, place ssh specific commands into ~/.bash_rsh. for instance:
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 <email@example.com> and extol the virtues
of a more robust scp. There has already been one suggestion to modify
scp ("Richard E. Silverman" <firstname.lastname@example.org>) 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" ]
# Put output here
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. ***