Unable to pipe shell commands

[staticfloat]

"OpenSSH for Windows" version
8.1.0.0p1-Beta

Server OperatingSystem
Windows Server 2019 Datacenter

Client OperatingSystem
Linux and MacOS tested.

What is failing
I expect to be able to pipe commands through ssh to the shell on the windows side. See this issue in the Visual Studio Code remote SSH repository for an example of where this functionality is expected: microsoft/vscode-remote-release#25 (comment)

Quick reproducer:

$ echo "echo test" | ssh -T win64bot3
shell request failed on channel 0

Expected output

I expect this to output test.

Actual output

It outputs shell request failed on channel 0

Running psexec -s sshd.exe -ddd on the server gives the following output:

...
Starting session: shell for administrator from fd37:5040::6639:ae1b:3e46:1517 port 50566 id 0
debug2: fd 9 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug2: fd 11 setting O_NONBLOCK
debug2: fd 12 setting O_NONBLOCK
debug2: fd 13 setting O_NONBLOCK
debug2: fd 14 setting O_NONBLOCK
debug3: shell: "c:\\windows\\system32\\cmd.exe"
debug3: shell_option: /c
debug3: exec_command: (null)
debug3: send packet: type 100
Connection closed by fd37:5040::6639:ae1b:3e46:1517 port 50566
debug1: channel 0: free: server-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 server-session (t10 r0 i0/0 o0/0 e[closed]/0 fd -1/-1/-1 sock -1 cc -1)

Close session: user administrator from fd37:5040::6639:ae1b:3e46:1517 port 50566 id 0
debug3: session_unused: session id 0 unused
debug1: do_cleanup
...

This makes me think that what is happening is the shell_option and exec_command shown above are interacting badly with the pipe-form of ssh. Note that if I instead run ssh -T win64bot3 "echo test", it works fine.

[mgkuhn]

Assuming the Windows shell configured for your OpenSSH server is the default cmd.exe, try

$ echo "echo test" | ssh win64bot3 cmd
Microsoft Windows [Version 10.0.18363.592]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\>echo test
test

C:\>

or without the chatty version and copyright message

$ echo "echo test" | ssh win64bot3 'cmd /k'
C:\>echo test
test

C:\>

I don't know how to suppress the prompts though, but considering that on the Windows command line I also get all that with

C:\>echo echo test | cmd
Microsoft Windows [Version 10.0.18363.592]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\>echo test
test

C:\>

I wouldn't expect OpenSSH to give me just

$ echo "echo test" | ssh win64bot3
test

as I don't see yet any documented way to start up cmd.exe in a way where it would accept commands from stdin without printing its prompts. It seems cmd supports such a quiet startup only if you pass it a command as an argument after /c, but not via stdin. (The latter would seem a useful feature request for cmd.exe.)

[roblourens]

In our original scenario (microsoft/vscode-remote-release#25) I can't pass cmd as the original command like in your example, because I am actually probing to check whether the remote is running windows or linux, then sending the correct script after that.

[mgkuhn]

@roblourens Probing what shell is started at the other end sounds like a rather brave idea: there is not only cmd but also powershell, bash, zsh etc., and how their interactive outputs look like can differ quite a bit between pre-ConPTY and with ConPTY being used.

But if that's what you are after, you definitely do want to see the cmd version string.

In my own code, I just add a configuration option what shell is to be expected at the other end.

[maertendMSFT]

Fixed, this will be part of our next release.