Bug 2338

Summary:

scp -3 doesn't give an error on missing source directory

Product:

Portable OpenSSH

Reporter:

Jakub Jelen <jjelen>

Component:

scp

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED WONTFIX

Severity:

normal

CC:

djm, jrwren

Priority:

Version:

6.7p1

Hardware:

Other

OS:

Linux

Attachments:

Description	Flags
Patch to show errors from remote ends	none

Description Jakub Jelen 2015-01-14 20:36:06 AEDT

This bug was created as a copy from RHBZ#1159307 (https://bugzilla.redhat.com/show_bug.cgi?id=1159307)
------------------------------------------------
Description of problem:

scp -3r a:foo user@b:

foo didn't exist, but scp gave no error message.

(a and b are rhel7 boxen, also seems to happen if a is rhel5, so I think it's actually the client end, which is my f21 laptop)

Version-Release number of selected component (if applicable):
openssh-clients-6.6.1p1-5.fc21.1.x86_64 (my laptop)
openssh-server-6.4p1-8.el7.x86_64 (RHEL7 host a and b)

How reproducible:
100%

Steps to Reproduce:
1. scp -3r a:foo b:
    where foo doesn't exist

Actual results:
Apparent success

Expected results:
An error, since foo didn't exist on the source

Additional info:
adding -v shows:

Sink: scp: foo: No such file or directory


Comment 1 Jakub Jelen 2015-01-14 10:21:51 CET

I tried this use case also with upstream release and it behaves the same.

In man page of scp, there is note:
> Note that this option disables the progress meter.

And I would say that this issue is related to this note, because the file transfer is made through the local host and the inputs and outputs of both remote commands are connected (but it doesn't change the thing that stderr should output).

All the behaviour of -3 option is quite strange, since the errors from source system are written only with -v option and errors from target system are never written.

I can try to place the question into openssh bugzilla, but upstream is not much willing to maintain scp.

For more information, this feature is related to this bugzilla [1], but without much discussion.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=1837

------------------------------------------------

Not sure if it is feature or bug. I would like to get some opinion or clarification from the authors.

Comment 1 Jakub Jelen 2015-04-23 23:08:34 AEST

Created attachment 2600 [details]
Patch to show errors from remote ends

To catch up with Red Hat bugzilla: Implementation of extended remote to remote is sending error messages back and forth from one remote to the other and none of them is writing them out. It seems half-baked.
This can be solved by catching such messages in initiator process (or writing them out in the remote processes, but it requires changes on server side).

After some digging in this case I managed to make stream redirection and catching errors in the initiator process. This change doesn't require any changes on server side so there are no drawbacks about backward compatibility.

For now it is fully functional implementation. Some notes for future self (or anyone having look into it):
 * Follows scp state protocol in simple FSM
 * It would be nicer to use atomicio everywhere (I read all line instead of reading byte after byte as implementation on server side)
 * Progress-meter is working again
 * Still doesn't work using password authentication on both ends, since the prompts are print over each other.
 * There is some overhead, but if you aim for speed you will not use -3 option

I tried my best to come up with quality code, but feel free to comment if you find some problem or something is not clear. Patch can be applied to upstream sources

Comment 2 Jakub Jelen 2017-08-17 17:33:10 AEST

*** Bug 2761 has been marked as a duplicate of this bug. ***

Comment 3 Damien Miller 2022-07-01 14:57:23 AEST

We're moving away from rcp-based scp, and the new sftp-based scp does show the error message

Comment 4 Damien Miller 2022-10-04 21:58:01 AEDT

Closing bugs from OpenSSH 9.1 release cycle