scp not tolerant of extraneous shell messages

[Darren Evans]

A workaround for sftp is to comment out fortune from the shell
startup script allowed sftp to work, presumably too much information,
may be useful to know of other circumstances for FAQ.

Interestingly, I just tested this with 3.4p1 connecting to 3.3p1
server and it stills display's this behaviour, just add fortune
to .bashrc to see it fudge.

$ sftp user at myhost
Connecting to myhost..
Received message too long 1113942382

$ scp user at myhost:file localhost
Q:  What's tan and black and looks great on a lawyer.

Could be humurous under different cirsumstances.

Regards,
Darren

Monday, July 1, 2002, 6:22:33 PM, you wrote:

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

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

BL> - Ben

BL> 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