Skip to content

copytool: support native Windows OpenSSH#5299

Draft
jandubois wants to merge 1 commit into
lima-vm:masterfrom
jandubois:copytool-native-windows-openssh
Draft

copytool: support native Windows OpenSSH#5299
jandubois wants to merge 1 commit into
lima-vm:masterfrom
jandubois:copytool-native-windows-openssh

Conversation

@jandubois

@jandubois jandubois commented Jul 21, 2026

Copy link
Copy Markdown
Member

On Windows, limactl copy converted host paths to the Cygwin/MSYS form no matter which ssh would consume them, and it passed ControlMaster options unconditionally. Native OpenSSH cannot use that path form, and it lacks multiplexing altogether, so scp failed with getsockname failed.

Paths now go through the ssh.exe that will consume them.

Part of a series continuing the native Windows OpenSSH work from #5205 and #5270: #5298, #5299, #5300, #5301. They are independent and can merge in any order. #5298 and #5301 both touch pkg/sshutil/sshutil.go, in different functions, and apply cleanly in either order.

Note that the Windows CI runner uses MSYS2 / Git for Windows, so it exercises the Cygwin path. TestParseCopyPathsWindowsDriveLetter runs there, but end-to-end validation on a plain Windows host, with no Cygwin toolchain present, arrives with the plain-Windows CI jobs in a later PR.

On Windows, `limactl copy` converted host paths to the Cygwin/MSYS
form no matter which ssh would consume them, and it passed
ControlMaster options unconditionally. Native OpenSSH cannot use that
path form, and it lacks multiplexing altogether, so scp failed with
"getsockname failed".

Paths now go through the ssh.exe that will consume them.

Signed-off-by: Jan Dubois <jan.dubois@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant