6

When I try to scp a file with a slash in its path, the path is quoted for the local host, and the last path component is additionally quoted for the remote host, like scp host:"a/b/'c'" ., it fails with

protocol error: filename does not match request

unless I use the -T option. However, if any other path component is quoted, like scp host:"a/'b'/c" ., it works. Also, if the path is not quoted for the local host, like scp host:a/b/'c' ., it works.

The man page documents -T as:

Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.

I don't understand how this description explains the behavior I see. What is the rationale for scp's behavior? And is there any way to disable this "feature"?

I am running Ubuntu 16.04 and the remote host is running Ubuntu 12.04.

Improve this question
9
  • Maybe the remote system removes the quotes and actually sends a file a/b/c which will be copied to ./c on your local system. A file c does not match your pattern "'c'". You disable the check with option -T. If you quote the directory 'b' you will get a file named c irrespectively how the remote system interprets a/'b'. As the transferred file matches the specified pattern you don't need -T.
    – Bodo
    Feb 11, 2019 at 15:13
  • @Bodo That is a plausible explanation. Perhaps scp doesn't know what shell the remote host uses so it isn't sure that it can canonicalize 'c' to c. But it is terribly inconvenient.
    – Reinstate Monica
    Feb 11, 2019 at 16:08
  • What do you expect to be copied by scp host:"a/b/'c'" .? A file c? A file 'c' with single quotes in its name?
    – Bodo
    Feb 11, 2019 at 16:13
  • @Bodo I expect a/b/'c' to pass to the remote shell and the remote shell to interpret it as file c in folder a/b. In other words, the file names stored in the filesystems on the remote and local hosts would both be c. So ideally there would be no error without -T. And the local scp knows that it specified 'c' and got back c. But it might not know that the two are the same in the respective filesystems.
    – Reinstate Monica
    Feb 11, 2019 at 16:14
  • Why do you have the nested quotes? If you execute cp "a/b/'c'" . the cp command would try to copy a file 'c' because the inner single quotes are quoted by the outer double quotes. Your expectation how scp should interpret your strange file name might be confusing for others (for the authors of scp).
    – Bodo
    Feb 11, 2019 at 16:24

1 Answer 1

Reset to default
3

Ubuntu people are known for pushing through inconsiderate/partial patches (recent example); in your case, it's about this patch, which is less than 3 weeks old, including the time spent in snapshots:

check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.

This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.

For this reason, this also adds a new -T flag to disable the check.

reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@

OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda

That is not ready for prime time (it's naively using fnmatch(3) on the basename of the file) and already had to fixed to allow for brace expansions.

Conclusion: it's a bug; it'll probably be fixed sooner or later; or if not, be prepared to always disable this new misfeature with -T.

Improve this answer
1
  • Apologies, I'm new on this site and didn't know scp would behave differently on Ubuntu than on other distros.
    – Reinstate Monica
    Feb 12, 2019 at 12:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .