Bug 1754

Summary: Can not copy from directories with space.
Product: Portable OpenSSH Reporter: Коренберг Марк <socketpair>
Component: scpAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED WONTFIX    
Severity: normal CC: dtucker
Priority: P2    
Version: 5.1p1   
Hardware: Other   
OS: Linux   

Description Коренберг Марк 2010-04-11 17:19:45 AEST
mmarkk@ubuntu:~$ scp host.ru:/home/mmarkk/some\ dir/file.ext .
mmarkk@host.ru's password: 
scp: /home/mmarkk/some: No such file or directory
scp: dir/file.ext: No such file or directory

It is able to copy to local dir with space. but

mmarkk@ubuntu:~$ scp /etc/passwd host.ru:/mnt/rw_disc/qwe\ qwe/
mmarkk@host.ru's password: 
scp: ambiguous target
Comment 1 Darren Tucker 2010-04-11 17:36:27 AEST
Actually you can, but you need to double-quote the argument since it gets processed twice: once by the local shell and once by the remote shell.

Both of these work:
$ scp "localhost:/tmp/foo\ bar/baz" baz
$ scp localhost:/tmp/foo\\\ bar/baz baz

Your local example works because it's only processed once by the local shell.
Comment 2 Коренберг Марк 2010-04-11 17:40:11 AEST
I think, that when issuing command on remote shell, scp SHOULD escape strings.
Comment 3 Коренберг Марк 2010-04-11 17:43:24 AEST
If not, it is security vulnerability - suppose one have automatic scp commands on some server. Specifying bad file name may cause executing commands or accessing files on remote side.

double-quoting may cause compatibility problems in future, when this bug will be eliminated.
Comment 4 Darren Tucker 2010-04-11 18:05:20 AEST
(In reply to comment #2)
> I think, that when issuing command on remote shell, scp SHOULD escape
> strings.

You can't reliably do this: there's no way for scp to know what the remote shell is and thus what its escaping rules are.  There's no guarantee it has the same rules as the local shell.

(In reply to comment #3)
> If not, it is security vulnerability - suppose one have automatic scp
> commands on some server. Specifying bad file name may cause executing
> commands or accessing files on remote side.

If the (restricted) shell you're using allows executing commands based on the content of the filenames then you have a problem with either the shell or its config.  Also, relying on client-side escaping as a security measure is worthless even if you could do it reliably, which you can't.

> double-quoting may cause compatibility problems in future, when this
> bug will be eliminated.

This is fundamentally unfixable within the scp "protocol", such as it is.  If this bugs you then use sftp instead since the filename are encoded in a defined way within the protocol and not subject to the vagaries of shell processing.

See http://www.openssh.com/faq.html#2.10
Comment 5 Darren Tucker 2010-04-23 10:25:16 AEST
Sorry, but as per the FAQ we won't be changing this.
Comment 6 Damien Miller 2011-01-24 12:33:31 AEDT
Move resolved bugs to CLOSED after 5.7 release