scp not tolerant of extraneous shell messages

[Ben Lindstrom]

You are really looking for sftp which has no shell dependancies.

But in general. No.. Fix your startup scripts.  scp is rcp in a ssh
wrapper.  and rcp will also fail.

- Ben

On Mon, 1 Jul 2002, Bryan Henderson wrote:

> I spent some time debugging a failing Scp that turned out to be caused
> by the remote shell producing messages on Standard Output that aren't
> part of the SCP protocol.
>
> Scp from a remote system works by running another Scp on the remote
> system.  The remote Scp writes SCP protocol messages (and file data)
> to its Standard Output, which the local Scp sees as Standard Input.
>
> But it's important to note that the remote Scp runs in a shell, and
> not just any shell -- an interactive shell.  It's an interactive shell
> because its Standard Input and Standard Output are terminals, and the
> shell knows it and makes some decisions based on the assumption that
> there's a human being there.  This makes Scp analogous to the file
> download function of an old-fashioned terminal emulator -- it's making
> automated use of a data stream intended for an intelligent human.
>
> So lets say the remote interactive shell puts an informational message
> on Standard Output as it starts up (mine does).  The local SCP
> responds by issuing the received line verbatim, with no additional
> context, as an error message, and terminates.  It apparently assumes
> that anything the shell says before remote Scp starts running must be
> a message explaining why it cannot run Scp.  And that the message
> contains enough context that the Scp user will be able to tell what to
> fix and where.
>
> But the message may just be informational, in which case Scp terminates
> needlessly, and with no apparent indication of why.
>
>
> I propose that local Scp just ignore all messages on Standard Input until
> it sees something that looks like an SCP control record.  If it never sees
> an SCP control record, it should issue an error message saying so, and
> include the last thing it _did_ see in that message.
>
> If there isn't something fundamentally wrong with this approach, I'll
> submit a patch.
>
>
> Ideally, I'd like to see a way to run remote Scp not in a shell at
> all.  It would be far more robust and faster.  Does the SSH protocol
> allow for such a thing?
>
> --
> Bryan Henderson                                    Phone 408-621-2000
> San Jose, California
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>