scp not tolerant of extraneous shell messages

Bryan Henderson bryanh at giraffe-data.com
Tue Jul 2 03:02:53 EST 2002


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



More information about the openssh-unix-dev mailing list