[HPR-888] ssh: use sftp by default for transferring files#160
[HPR-888] ssh: use sftp by default for transferring files#160lbajolet-hashicorp wants to merge 1 commit intomainfrom
Conversation
Recently Windows's SSH server implementation has changed the way they set the MOTW on the receiving end for file transfers, which coupled with the way Packer invokes the command, causes the transfers to fail since the command exits with a non-zero error code. While this is going to be fixed in an upcoming release, we are changing the default method for transferring data from the host to the guest from scp to sftp. This is motivated in part by the aforementioned problem with Windows's SSH server, but also by a decision on the OpenSSH part, where with version 9, they also decided to not use scp the protocol for sending/receiving files, and even when using the `scp' client, the protocol would default to sftp. Given both decisions, coupled with the fact that scp is insecure and obsolete, we change the default method for transferring files between endpoints to sftp by default.
|
These changes look good so far but lets not merge at this time. It will take some coordination across builder components. We can import this SDK from the the branch and test locally before merging. |
|
Coming back to this one, I ran a subset of the acceptance tests on both the amazon and the googlecompute plugins with a local replace directive in the Both show the following in their logs: From the looks of it, it seems that the change works, I'll make sure we don't have a problem when transferring directories in addition to commands, but I think we can consider merging this PR soon. |
|
Regarding directories, I notice that the two protocols behave differently, and while sftp works for most use-cases, we should make sure that the two behave the same so that we don't unexpectedly break some clients. |
Recently Windows's SSH server implementation has changed the way they set the MOTW on the receiving end for file transfers, which coupled with the way Packer invokes the command, causes the transfers to fail since the command exits with a non-zero error code.
While this is going to be fixed in an upcoming release, we are changing the default method for transferring data from the host to the guest from scp to sftp.
This is motivated in part by the aforementioned problem with Windows's SSH server, but also by a decision on the OpenSSH part, where with version 9, they also decided to not use scp the protocol for sending/receiving files, and even when using the `scp' client, the protocol would default to sftp.
Given both decisions, coupled with the fact that scp is insecure and obsolete, we change the default method for transferring files between endpoints to sftp by default.