I have installed OpenSSH for Windows on a Windows 2000 box, and am running Mandrake 9.? on another machine. I get the problem below when trying to use scp to transfer from Windows to Linux. This behaviour prevents me from doing a remote Windows to remote Linux transfer, in addition to requiring the special syntax when transferrng from Windows to the local machine. # Version. ssh -v OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f <snip> # Version. scp -v <?> # This works. scp sourceid@windowsmc:c:/sourcefile /a/directory/sinkfile # This produces an error. scp sourceid@windowsmc:c:/sourcefile sinkid@linuxmc:/a/directory/sinkfile ssh: c: no address associated with name dajo
Sorry, but we won't implement workarounds for windows paths in portable OpenSSH. Instead, you can use the Cygwin 'mount' utility to eliminate the need to use them at all. See the documentation at: http://www.cygwin.com/cygwin-ug-net/using.html
Comment #1 is a surprise to me. Certainly I understand not implementing a workaround; but I do not understand how this is a windows path workaround. As I hope the example shows, a successful transfer from windows to linux works, provided that the destination is the box running the scp command. The problem occurs when a third machine is identified, i.e., a remote windows to *remote* linux transfer. DESCRIPTION <snip> Any file name may contain a host and user specification to indicate that the file is to be copied to/from that host. Copies between two remote hosts are permitted. <snip> At this point I do not understand my own comment about special syntax, and it seems that it only confuses the main issue, and should be ignored. A workaround that I am using is simply to do two transfers: to and from the scp host. This suits my application better than using mount. Thanks for looking at the (maybe not) bug report.
Actually this may be a cygwin bug. From your example: scp sourceid@windowsmc:c:/sourcefile sinkid@linuxmc:/a/directory/sinkfile ssh: c: no address associated with name It looks like something is intepreting the final 'c' and the two following characters as a Windows-style path. OpenSSH's scp certainly doesn't do this, so I expect that it would be Windows itself or one of the Cygwin DLLs that OpenSSH links against. What does turning up the debugging do. i.e "scp -v"
Here is the key output using -v. There does appear to be something wrong with the second exec of ssh. scp-linuxhost-prompt> scp -v sourceid@windowsmc:c:/sourcefile sinkid@linuxmc:/a/directory/sinkfile Executing: /usr/bin/ssh -v -x -o'ClearAllForwardings yes' -n -l sourceid windowsmc scp -v c:/sourcefile 'sinkid@linuxmc:/a/directory/sinkfile' OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * <snip> Executing: exec /usr/bin/ssh -v -x -o'ClearAllForwardings yes' -n c scp -v /sourcefile 'sinkid@linuxmc:/a/directory/sinkfile' OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh_config ssh: c: no address associated with name <snip>
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.