subsystem executable paths with "spaces" do not work

[philSixZero]

"OpenSSH for Windows" version v0.0.16.0

Server OperatingSystem Windows 7 Enterprise

Client OperatingSystem UBuntu 16.04 / 16.10

What is failing Execution of powershell as subsystem.

Actual output I configured the sshd_config file as follows: Subsystem powershell C:\Program Files\PowerShell\6.0.0.17\powershell.exe -sshs -NoLogo -NoProfile

The sshd log file states following message regarding to the execution of the subsystem: 2956 11:50:35:760 debug1: Executing command: C:\\Program Files\\OpenSSH\\C:\\Program Files\\PowerShell\\6.0.0.17\\powershell.exe -sshs -NoLogo -NoProfile

This fails and the connection crushes. So I set the path in the sshd_config relatively to the OpenSSH folder: Subsystem powershell ..\PowerShell\6.0.0.17\powershell.exe -sshs -NoLogo -NoProfile which fixed the issue.

Is it only me experiencing this or had any of you the same issue?

[bagajjal]

@philSixZero - I tried this and got a different error. 1) What does this command do ? C:\Program Files\PowerShell\6.0.0.17\powershell.exe -sshs -NoLogo -NoProfile

2) Here is the analysis, My sshdconfig - Subsystem powershell C:\Program Files\PowerShell\6.0.0.14\powershell.exe -sshs -NoLogo -NoProfile

When I tried to do ssh using "./ssh.exe localadmin@127.0.0.1 -s powershell".. my sshd.log shows that it executed the correct path but failed with different error message.

Logic - When you specify a relative path, we add the sshd.exe path. This is the reason it works fine.

sshd.log- 42292 17:54:16:346 debug1: subsystem: exec() C:\Program Files\PowerShell\6.0.0.14\powershell.exe -sshs -NoLogo -NoProfile 42292 17:54:16:346 Starting session: subsystem 'powershell' for localadmin from 127.0.0.1 port 34233 id 0 42292 17:54:16:346 debug3: pipe - r-h:412,io:00000280A9F525E0,fd:7 w-h:288,io:00000280A9F526D0,fd:8 42292 17:54:16:346 debug3: pipe - r-h:420,io:00000280A9F9BEE0,fd:9 w-h:416,io:00000280A9F9BFD0,fd:10 42292 17:54:16:346 debug3: pipe - r-h:428,io:00000280A9F9C0C0,fd:11 w-h:424,io:00000280A9F9C1B0,fd:12 42292 17:54:16:347 debug2: fd 7 setting O_NONBLOCK 42292 17:54:16:347 debug2: fd 8 setting O_NONBLOCK 42292 17:54:16:347 debug2: fd 9 setting O_NONBLOCK 42292 17:54:16:347 debug2: fd 10 setting O_NONBLOCK 42292 17:54:16:347 debug2: fd 11 setting O_NONBLOCK 42292 17:54:16:347 debug2: fd 12 setting O_NONBLOCK 42292 17:54:16:347 debug1: Executing command: C:\Program Files\PowerShell\6.0.0.14\powershell.exe -sshs -NoLogo -NoProfile 42292 17:54:16:348 debug3: Register child 00000000000001B4 pid 42444, 0 zombies of 0 42292 17:54:16:348 debug2: fd 3 setting TCP_NODELAY 42292 17:54:16:349 debug3: close - io:00000280A9F525E0, type:2, fd:7, table_index:7 42292 17:54:16:349 debug3: close - io:00000280A9F9BFD0, type:2, fd:10, table_index:10 42292 17:54:16:349 debug3: close - io:00000280A9F9C1B0, type:2, fd:12, table_index:12 42292 17:54:16:349 debug3: fd 9 is O_NONBLOCK 42292 17:54:16:349 debug3: fd 8 is O_NONBLOCK 42292 17:54:16:349 debug3: fd 11 is O_NONBLOCK 42292 17:54:16:349 debug3: send packet: type 99 42292 17:54:23:530 debug2: channel 0: read 103 from efd 11 42292 17:54:23:531 debug3: channel 0: discard efd 42292 17:54:23:542 debug2: channel 0: read<=0 rfd 9 len 0 42292 17:54:23:542 debug2: channel 0: read failed 42292 17:54:23:542 debug2: channel 0: close_read 42292 17:54:23:542 debug3: close - io:00000280A9F9BEE0, type:2, fd:9, table_index:9 42292 17:54:23:542 debug2: channel 0: input open -> drain 42292 17:54:23:542 debug2: channel 0: read 0 from efd 11 42292 17:54:23:542 debug2: channel 0: closing read-efd 11 42292 17:54:23:542 debug3: close - io:00000280A9F9C0C0, type:2, fd:11, table_index:11 42292 17:54:23:542 debug2: channel 0: ibuf empty 42292 17:54:23:542 debug2: channel 0: send eof 42292 17:54:23:542 debug3: send packet: type 96 42292 17:54:23:542 debug2: channel 0: input drain -> closed 42292 17:54:23:547 debug3: zombie'ing child at index 0, 0 zombies of 1 42292 17:54:23:547 debug1: Received SIGCHLD. 42292 17:54:23:547 debug3: Unregister child at index 0, 1 zombies of 1 42292 17:54:23:547 debug1: session_by_pid: pid 42444 42292 17:54:23:548 debug1: session_exit_message: session 0 channel 0 pid 42444 42292 17:54:23:548 debug2: channel 0: request exit-status confirm 0 42292 17:54:23:548 debug3: send packet: type 98 42292 17:54:23:548 debug1: session_exit_message: release channel 0 42292 17:54:23:548 debug2: channel 0: write failed 42292 17:54:23:548 debug2: channel 0: close_write 42292 17:54:23:548 debug3: close - io:00000280A9F526D0, type:2, fd:8, table_index:8 42292 17:54:23:548 debug2: channel 0: send eow 42292 17:54:23:548 debug3: send packet: type 98 42292 17:54:23:548 debug2: channel 0: output open -> closed 42292 17:54:23:548 debug2: channel 0: send close 42292 17:54:23:548 debug3: send packet: type 97 42292 17:54:23:548 debug3: channel 0: will not send data after close 42292 17:54:23:548 debug2: notify_done: reading 42292 17:54:23:548 debug3: channel 0: will not send data after close 42292 17:54:23:548 debug3: receive packet: type 97 42292 17:54:23:548 debug2: channel 0: rcvd close 42292 17:54:23:548 debug3: channel 0: will not send data after close 42292 17:54:23:548 debug2: channel 0: is dead 42292 17:54:23:548 debug2: channel 0: gc: notify user 42292 17:54:23:548 debug1: session_by_channel: session 0 channel 0 42292 17:54:23:548 debug1: session_close_by_channel: channel 0 child 0 42292 17:54:23:548 Close session: user localadmin from 127.0.0.1 port 34233 id 0 42292 17:54:23:548 debug3: session_unused: session id 0 unused 42292 17:54:23:548 debug2: channel 0: gc: user detached 42292 17:54:23:548 debug2: channel 0: is dead 42292 17:54:23:548 debug2: channel 0: garbage collecting 42292 17:54:23:548 debug1: channel 0: free: server-session, nchannels 1 42292 17:54:23:548 debug3: channel 0: status: The following connections are open:\r\n #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)\r\n 42292 17:54:23:548 debug3: WSARecv - WSARecv() ERROR: io:00000280A9F52290 10054 42292 17:54:23:548 debug3: recv - from CB ERROR:108, io:00000280A9F52290 42292 17:54:23:549 Read error from remote host 127.0.0.1 port 34233: Unknown error 42292 17:54:23:549 debug1: do_cleanup

[bagajjal]

SSHD receive SIGCHLD from the ssh client so it closed the connection.

42292 17:54:23:530 debug2: channel 0: read 103 from efd 11 42292 17:54:23:531 debug3: channel 0: discard efd 42292 17:54:23:542 debug2: channel 0: read<=0 rfd 9 len 0 42292 17:54:23:542 debug2: channel 0: read failed 42292 17:54:23:542 debug2: channel 0: close_read 42292 17:54:23:542 debug3: close - io:00000280A9F9BEE0, type:2, fd:9, table_index:9 42292 17:54:23:542 debug2: channel 0: input open -> drain 42292 17:54:23:542 debug2: channel 0: read 0 from efd 11 42292 17:54:23:542 debug2: channel 0: closing read-efd 11 42292 17:54:23:542 debug3: close - io:00000280A9F9C0C0, type:2, fd:11, table_index:11 42292 17:54:23:542 debug2: channel 0: ibuf empty 42292 17:54:23:542 debug2: channel 0: send eof 42292 17:54:23:542 debug3: send packet: type 96 42292 17:54:23:542 debug2: channel 0: input drain -> closed 42292 17:54:23:547 debug3: zombie'ing child at index 0, 0 zombies of 1 42292 17:54:23:547 debug1: Received SIGCHLD.

[bagajjal]

The same thing works if you specify cmd.exe in sshd_config Subsystem mycmd C:\Windows\System32\cmd.exe

use ssh user@ip -s mycmd

[philSixZero]

Using a direct ssh session from Ubuntu to Windows with the "-s powershell" argument isn't working with this workaround. But somehow the "Enter-PSSession"-command in PowerShell 6 is only running with the relative path...

[manojampalam]

The issue is with space " " in the subsystem executable path (ProgramFiles). I checked the code and the current implementation does not support it.

As a work around, you could create a symlink (with no spaces in its path) the following way and specify the link in the subsystem path mklink /H c:\pslink.exe "C:\Program Files\PowerShell\6.0.0.17\powershell.exe"

Add this in sshd_config Subsystem powershell C:\pslink.exe -sshs -NoLogo -NoProfile

[bagajjal]

tested on the unix environment. Unix has a way to escape the spaces in the path.. ex - /home/Ubuntu/test\ directory/ -> Here we escape the space in "test directory" using .

We need to find a way that suits windows.

[dantraMSFT]

I hit the same issue on Server 2016 but found that neither mklink nor New-Item would create a usable symlink (The application to execute does not exist: 'C:\users\Public\pwsh.dll')

I ended up creating a directory link c:\powershell to resolve it.

[JustinGrote]

For those who came here from the MSFT documentation like I did, here's a script to automate the process on Windows.

https://gist.github.com/JustinGrote/72d7baaa6cc99691b7c4cb3caad54891

[Zerowalker]

How's this coming along?

[gildas]

For those who came here from the MSFT documentation like I did, here's a script to automate the process on Windows.

https://gist.github.com/JustinGrote/72d7baaa6cc99691b7c4cb3caad54891

Actually, there is absolutely no need for any script nor any hardlink, just basic knowledge of Windows PowerShell.... Just use the 8.3 notation of the path (with / instead of \) to pwsh.exe in sshd_config:

Subsystem       powershell C:/progra~1/PowerShell/6/pwsh.exe -sshs -NoLogo -NoProfile

IMO, there is no bug in the code as spaces are simply not allowed. Just use whatever the current OS uses to escape said spaces...

As a side note, for whatever reason restarting the sshd service was not enough for me, I had to restart the server.

[he852100]

Actually, there is absolutely no need for any script nor any hardlink, just basic knowledge of Windows PowerShell.... Just use the 8.3 notation of the path (with / instead of \) to pwsh.exe in sshd_config:

Subsystem       powershell C:/progra~1/PowerShell/6/pwsh.exe -sshs -NoLogo -NoProfile

In fact, progra-1 works. \No problem.

[maertendMSFT]

Our recommendation is to use 8.3 syntax. We will update the docs to describe this.

[fakhrulhilal]

I tried to use all of them, but none of them succeed:

#Subsystem  powershell  c:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo
#Subsystem  powershell  c:\progra~1\powershell\7\pwsh.exe -sshs -NoLogo
#Subsystem  powershell "C:\Program Files\PowerShell\7\pwsh.exe" -sshs -NoLogo
#Subsystem  powershell C:\Program Files\PowerShell\7\pwsh.exe -sshs -NoLogo
#Subsystem  powershell ..\PowerShell\7\pwsh.exe -sshs -NoLogo
Subsystem   powershell pwsh.exe -sshs -NoLogo

All of those config result the same log from event viewer for OpenSSH operational: sshd: subsystem request for powershell by user XXX failed, subsystem not found

This command ssh -v XXX@bfs-kx-sql1.kana-test.com -s powershell will result subsystem request failed on channel 0. Leaving -s argument will make it works. What do I miss?

Information: OpenSSH server version: OpenSSH_for_Windows_8.1p1, LibreSSL 2.9.2 OpenSSH client: OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 PowerShell on server: PS Core 7.0.2 pwsh command added in PATH environment

[eabase]

Why is that funny looking command switch -sshs not documented anywhere on the entire internet!?? (I'm getting pretty sure it is wrong...)

[JustinGrote]

It's documented in the source code 👍

It basically tells Powershell to do Remoting protocol xml to stdin/out

[eabase]

@JustinGrote Thank you, but can you pinpoint it to me, because searching here I can't find it. (Especially since there is no source code here.)

[JustinGrote]

It was a joke but it's in the github.com/powershell/powershell repository.

[eabase]

Any idea why it's not documented as a normal command argument?? pwsh /h certinly doesn't say anything.

[eabase]

ok found it here, but IMHO I wouldn't call that "documented"...

[eabase]

I want to confirm that neither of the methods used by @fakhrulhilal works. I also tried creating both SymbolicLink and HardLink to pwsh.exe and even via Registry edit, but all to no avail. For some reason the OpenSSH sshd_config, never respects the -NoLogo -NoProfile.

[bagajjal]

@eabase - If the issued is not resolved then please open a new issue as your problem seems to be with the arguments. Please note any changes to sshd_config requires a restart of sshd process (net stop sshd; net start sshd). Attach client side logs (ssh -vvv user@ip) and sshd server side logs with DEBUG3 enabled.

[eabase]

Why has this bug not been fixed? After all, it's been a good 3+ years since first reported...

[mwtrigg]

Why has this bug not been fixed? After all, it's been a good 3+ years since first reported...

It looks like it is an open source project; contributions are welcome.

[fakhrulhilal]

Why has this bug not been fixed? After all, it's been a good 3+ years since first reported...

It looks like it is an open source project; contributions are welcome.

But you don't expect people who're not familiar with the technology stack used in this repo to fix the code, right? Not all of them familiar with C/C++. Contribution doesn't have to be fixing code. Reporting the issue (with clear explanation) is a contribution as well.

[eabase]

@fakhrulhilal

Reporting the issue (with clear explanation) is a contribution as well.

Apparently not so much here. It seem that we're the 3σ fringe users and that the only ones actually using the native Windows OpenSSH, are a handful of paid MS developers already on the latest OS, tools and internal knowledge. Personally I thought it would be more maintainable and neat to use a native client, but I see now, it's still a dead old fish to revive, which is why I've been using Cygwin's SSH for ~25 years. Not even WSL is making this UX better. Windows could never catch up and always messed up settings and expected functionalities and compatibility etc. (Can't even get the default sshd_config file correct.) So for anything remote, apart running 1 or 2 commands, it's TeamViewer or Cygwins' SSH/SCP. Then there's the integration issues with PSReadLine: 42 years of VT100 ANSI and MS still can't get it right! :-1:

[vGruntus]

ok found it here, but IMHO I wouldn't call that "documented"...

@eabase, the (current) documentation does have this here. It's a shortened version of -SSHServerMode. I know it'd been a few years since this was noted, but thought I'd close the loop with the current documentation.

[guyrleech]

Unless I missed it, nobody mentions that escaping spaces with a \ in Windows does work unless it's new behaviour in Server 2025 which is what I am remoting to

To show the 8.3 paths, use dir /x in cmd.exe, noting that the short names are creation order dependent - "program files" is usually progra~1 because it is created before "program files (x86)" during Windows installation