View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014141CMakeCMakepublic2013-05-14 20:122016-06-10 14:31
ReporterCraig Scott 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinux 64-bitOSFedoraOS Version16
Product VersionCMake 2.8.10.1 
Target VersionFixed in Version 
Summary0014141: file(UPLOAD ....) fails with scp protocol using keys
DescriptionWhen using the file(UPLOAD .....) command with a destination url which specifies the scp protocol, it fails with an ambiguous error message. I've attached a small example script which triggers the problem for me every time, but the important line is one like this:

file(UPLOAD someFileToUpload.txt
     scp://myusername@somehost.somedomain/~/
     TIMEOUT 5
     INACTIVITY_TIMEOUT 10
     STATUS uploadResult
     LOG uploadLog
     SHOW_PROGRESS
)

 An example of the output follows:

  About to connect() to somehost.somedomain port 22 (#0)

    Trying 192.168.1.3... connected

  Connected to somehost.somedomain (192.168.1.3) port 22 (#0)

  SSH authentication methods available: publickey

  Using ssh public key file /home/myusername/.ssh/id_dsa.pub

  Using ssh private key file /home/myusername/.ssh/id_dsa

  Initialized SSH public key authentication

  Authentication complete

  SSH CONNECT phase done

  failed waiting for ACK

  Connection #0 to host somehost.somedomain left intact

  Error in the SSH layer

  Closing connection #0



The "failed waiting for ACK" error is pretty non-specific. A quick bit of googling suggests that this is a fairly generic error which could have various causes, but since no further information is provided and there's nothing in the logs on the server after authentication succeeds, I can't get any more info on what the underlying problem is. I've tried various combinations of host names and target directory paths, but always the same problem. Removing the username part from the url leads to authentication failure (as you'd expect). Using the sftp:// protocol fails as well, with the "failed waiting for ACK" message replaced with:

  Upload failed: Operation failed (4/-31)

If you try the exact same scp operation using curl at the command line, it succeeds. CMake is using libcurl under the covers and when I built cmake, I told it to use the system-supplied libcurl. This suggests that CMake is doing something wrong with how it is passing information to libcurl since the same operation when performed at the command line with curl directly works fine.
Steps To Reproduce1. Ensure private/public keys are set up and working (test with ssh at a command line).

2. Process the attached file with cmake using a command like the following:

   cmake -P uploadFails.cmake
 
NOTE: You could also embed similar commands in a real CMakeLists.txt file, but you get similar results.

3. Confirm that the equivalent operation can be performed successfully using curl at the command line. Eg:

   curl -v -T uploadFails.cmake scp://myusername@somehost.somedomain/~/
TagsNo tags attached.
Attached Files? file icon uploadFails.cmake [^] (324 bytes) 2013-05-14 20:12

 Relationships

  Notes
(0033037)
Craig Scott (reporter)
2013-05-14 20:15

 Looks like the bug tracker made a mess of the urls in the commands. Please look at the file I attached for the intended syntax.
(0033038)
Rolf Eike Beer (developer)
2013-05-15 02:19

 It's just when displaying it, the mail sent out looks good.

The first thing that I think may cause this is ~: the shell will most likely have expanded this before passing it to curl. Since you should be in your home directory after login on the remote side anyway I suggest just removing it. You can try to see if it's the problem if you pass the URL to libcurl in single quotes (') to prevent the shell from expanding this.
(0033039)
Craig Scott (reporter)
2013-05-15 02:33

 That's not the issue. I was originally using an absolute path without a ~ character, but same problem.
(0042279)
Kitware Robot (administrator)
2016-06-10 14:28

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-05-14 20:12 Craig Scott New Issue
2013-05-14 20:12 Craig Scott File Added: uploadFails.cmake
2013-05-14 20:15 Craig Scott Note Added: 0033037
2013-05-15 02:19 Rolf Eike Beer Note Added: 0033038
2013-05-15 02:33 Craig Scott Note Added: 0033039
2016-06-10 14:28 Kitware Robot Note Added: 0042279
2016-06-10 14:28 Kitware Robot Status new => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team