multipass.exe in Windows is not redirecting STDIN

[lars18th]

Describe the bug

• When using the multipass.exe Windows version of the CLI tool, this binary is not supporting any STDIN redirection. Instead it attach directly to the terminal API (or something else, but you can read but not write with a PIPE connected to this binary).

To Reproduce
You can test it trying to stablish a PuTTY session with the ssh-connection protocol:

1. You have previosly installed the psusan tool with sudo apt install putty-tools inside the virtual machine.
2. plink.exe -ssh-connection -sshlog .\plink.log -proxycmd "D:\multipass.exe exec vmname -- psusan" dummy
3. The command starts, but nothing happens.

How, and what happened?

1. The problem seems that something fails with the multipass.exe STDIN redirection.
2. You can check that the psusan process is running inside the vmname doing another multipass shell vmname and ps -ae | grep psusan.
3. You can check as well that the connection is not stablished (with more plink.log).
4. The worse is that if you close the plink.exe with a CTRL+C, the psusan and the ssh connection continues running. You need to kill it inside the virtual machine.

Expected behavior
The same command in a Linux host with identical configuration works like a charm:

plink -ssh-connection -sshlog ./plink.log -proxycmd "multipass exec moved-lanternfish -- psusan" dummy
ubuntu@moved-lanternfish:~$ uname -a
Linux moved-lanternfish 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@moved-lanternfish:~$ exit
logout

Logs
Because this is pure command line, no multipass_gui.log exist.
You can see the plink.log running with the Windows version:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2024.10.19 14:44:45 =~=~=~=~=~=~=~=~=~=~=~=
Event Log: Sharing this connection at \\.\pipe\putty-connshare.User.37caef9fe9b3ea3ead77271d98785be30ee053c44f403262b375e2c8abe691ed
Event Log: Leaving host lookup to proxy of "dummy" (for SSH connection)
Event Log: Starting local proxy command: D:\\multipass.exe exec test2404 -- psusan
Event Log: We claim version: [email protected]_Release_0.80
Event Log: Connected to dummy
Event Log: Remote version: [email protected]_Release_0.81
Event Log: Using SSH protocol version 2
Event Log: Opening main session channel
Outgoing packet #0x0, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
  00000000  00 00 00 07 73 65 73 73 69 6f 6e 00 00 01 00 00  ....session.....
  00000010  00 40 00 00 00 40 00                             .@...@.

This indicates that the multipass.exe is writing to the STDOUT, because the line:
Event Log: Remote version: [email protected]_Release_0.81
is writed from the other end (the psusan process) and it arrived to the plink tool that reads from the STDOUT connected to the multipass process. However, the STDIN is NEVER readed from the multipass process. Therefore, nothing arrives to the other end.

Additional info

• OS: Microsoft Windows [Version 10.0.22631.4317]
• multipass version:
  • multipass 1.14.1+win
  • multipassd 1.14.1+win
• multipass info:

Name:           vmname
State:          Running
Snapshots:      0
IPv4:           172.30.227.4
Release:        Ubuntu 24.04.1 LTS
Image hash:     fad101d50b06 (Ubuntu 24.04 LTS)
CPU(s):         1
Load:           0.00 0.00 0.00
Disk usage:     1.8GiB out of 4.8GiB
Memory usage:   317.3MiB out of 896.3MiB
Mounts:         --

• multipass get local.driver:
  • hyperv

Additional context
Similar effect appears if you try to run the tool from WSL. Nothing is readed from the STDIN pipe.

I hope you will fix this soon. To put the windows cli tool in pair with the linux version.

And additionally try to fix the closing of ssh connections to the virtual machine if the multipass process cannot establish the connection. With these tests I ended up with a lot of phantom multipass processes on the Windows workstation. All because the CTRL+C of the incomplete connection doesn't terminate the process.

[georgeliao]

@lars18th
Thanks for reporting this. I fiddled this and I can reproduce the same behavior. It is something we can try to fix in the future.

[lars18th]

I fiddled this and I can reproduce the same behavior. It is something we can try to fix in the future.

Good news! 👍

[ricab]

Possible duplicate of #1170

[lars18th]

Possible duplicate of #1170

Hi @ricab ,

I'm not sure, but I think it might be involuntarily fixed in #3735.
I think so because there is a commit that says: "[ssh] Set stdin to Raw only after libssh inherits sane settings".

And I can't test it personally because the Windows client source code is hidden. Perhaps you could compile one version with this patch and test it.