Here is the workaround that worked for me (taken from https://github.com/PowerShell/Win32-OpenSSH/issues/895):

On the server with Windows OpenSSH:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShellCommandOption -Value "/c" -PropertyType String -Force

Then add %SystemRoot%\System32\OpenSSH to the System Environment PATH variable.
Reboot (services read environments only at computer startup)

The path change allows the scp.exe to be found by powershell.

Our product is running Windows only atm. So we need to deploy it via ssh / scp.  

Would be nice if this was working out of the box but sadly its not.

I ran into this issue as well trying to transfer files to PowerShell OpenSSH.  As a workaround, I stopped setting a path but the file still gets uploaded with 'file.ext'. sshj supports configuring the type of escaping used when performing SCP.  Can we have the escaping exposed as a configuration option on the scp task?

https://static.javadoc.io/com.hierynomus/sshj/0.24.0/net/schmizz/sshj/xfer/scp/ScpCommandLine.EscapeMode.html

I worked around this by using an SSH task and ftp'ing the file using CURL

curl --insecure --user UID:PWD -T <source_file>sftp://<server_name>/<drive>/<directory>/<target_name>

Hello, Bamboo indeed escapes paths with single quotes, however the problem occurs on a target server when path provided by Bamboo is appended to a SSH server 'base path' as a result file ends up wrapped with quotes. Because of that fact we believe it's a matter of configuration of target SSH server.

That being said, I changed this issue type to Improvement to improve Bamboo's SCP handling in such cases. The description contains a list of Windows SSH servers which work properly, whereas Cygwin is recommended one.

Best regards,
Grzegorz Lewandowski
Bamboo Development Team

We are experiencing the same issue - Bamboo 6.5.0 & OpenSSH server on Windows

Addendum to my above. There is one more scenario that passes the single quotes:

[develop@wesnixnaepci1 ~]$ scp mytest.txt "builduser@webnaeptest:'mytest.txt'"

This example corresponds to the central idea that the single quoted filename is somehow being wrapped in double quotes prior to transmission.

After experiencing this issue and requesting assistance, I conducted the following experiments and reached the below conclusions:

TL:DR; The SCP Task is sending the filename as a double quote wrapped, single quoted string. Where it is succeeding in saving an unquoted filename, it is by accident and not design.

Experiments

The following produces mytest.txt on target, this is the expected result:

[develop@wesnixnaepci1 ~]$ scp mytest.txt builduser@webnaeptest:mytest.txt
[develop@wesnixnaepci1 ~]$ scp mytest.txt builduser@webnaeptest:'mytest.txt'
[develop@wesnixnaepci1 ~]$ scp mytest.txt builduser@webnaeptest:"mytest.txt"

The following produces 'mytext.txt' on target (note embedded quotes), this produces the anomalous behavior:

[develop@wesnixnaepci1 ~]$ scp mytest.txt builduser@webnaeptest:"'mytest.txt'"

[note that this is double quotes around single quotes around filename]

Conclusion

For this particular server, PowerShell OpenSSH, it is demonstrated that the only reliable way to replicate the issue is by deliberately creating a double quoted single quoted filename. Further, it is asserted that if this is the case, the OpenSSH server is behaving correctly by honoring the embedded single quotes.

Therefore, I surmise that the analysis was incorrect; it's not that some servers were failing, it's that some servers were accidentally succeeding by stripping out extraneous quotation marks. My hypothesis is that the file information is being inadvertently quoted twice, the inner is single quotes which is why the server (correctly as it turns out) includes the single quote as part of the filename.

We are experiencing the same issue.  This prevents us from SCP-ing to our Windows server using the Bamboo SCP plugin.  We consider this more severe than minor because the quotes cause any file specified with a path to file.

e.g. test.txt shows up as 'test.txt' but c:\temp\test.txt will fail all together.