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.
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. ***