Is this a powershell or OpenSSH issue? "-sshs -NoLogo -NoProfile" not respected"

Question

Is this a powershell or OpenSSH issue? "-sshs -NoLogo -NoProfile" not respected"

eabase opened this issue 4 years ago · 13 comments

eabase commented 4 years ago

The following issues have been raised in the Win32-OpenSSH repo:

It describe how the Subsystem .../pwsh.exe -sshs -NoLogo -NoProfile is not being respected.

It's not clear if this is a powershell issue or a Win32-OpenSSH issue?

Answer 1 · 2020-10-06T18:03:52.000Z

@eabase

Can you please provide all the necessary information that's required when submitting the issue?

Is this Windows PowerShell? PowerShell 7? or, PowerShell Preview.
Is this on Windows 10? or Server?
What's the OS Build?
How can we reproduce the error?

Use the $PSVersionTable, as it has been laid out when creating the issue in this repository.

All this information will help in getting to the bottom of the issue you're experiencing.

Thank You!

Answer 2 · 2020-10-06T19:03:02.000Z

The Subsystem is only used as part of a PSRemoting session, through cmdlets like Enter-PSSession and Invoke-Command so from that perspective it is working as intended. There's no logo that will appear when you do an interactive PSRemoting session through Enter-PSSession and -NoProfile is being honoured correctly by it not loading the profile on a logon.

When you run ssh username@hostname it isn't using that Subsystem at all, but rather the Default* properties under HKLM:\SOFTWARE\OpenSSH\ to define what application to use for the shell and what args to run with it. If that isn't working then you need to go through the SSH repo and ask there as it isn't a problem with PowerShell.

Answer 3 · 2020-10-06T20:13:17.000Z

@MaximoTrinidad

"OpenSSH for Windows" version

7.7.2.2

Server OperatingSystems

  OS Name               : Microsoft Windows 10 Home (64-bit)
  OS Version            : 10.0.18363  [2020-09-09 12:38:59 AM]
  OS BuildLabEx         : 18362.1
  OS HAL                : 10.0.18362.752
  OS Kernel             : 10.0.18362.1110
  OS UBR                : 1110

Client OperatingSystem

I tried both:

Win10 Home
Win 8 Home +/- Cygwin

PowerShell Version : 5.1.18362.1110

But I want to run it on Core 7.0.3 and that doesn't seem to work... possibly because of spaces in path definition.

Answer 4 · 2020-10-06T20:21:03.000Z

@jborean93

When you run ssh username@hostname it isn't using that Subsystem at all, but rather the Default* properties under HKLM:\SOFTWARE\OpenSSH\ to define what application to use for the shell and what args to run with it.

Wow! Now that is something important to tell the OpenSSH people about!

The Subsystem is only used as part of a PSRemoting session, through cmdlets like Enter-PSSession and Invoke-Command so from that perspective it is working as intended. There's no logo that will appear when you do an interactive PSRemoting session through Enter-PSSession and -NoProfile is being honoured correctly by it not loading the profile on a logon.

I'm not using those cmdlets, I'm just using standard ssh sessions. So, no that is what seem to be broken then.

After setting:

Set-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Program Files\PowerShell\7\pwsh.exe"
Set-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShellCommandOption -Value "-NoLogo -NoProfile -c"

It still loads the profile and logos.

Answer 5 · 2020-10-06T20:47:32.000Z

Wow! Now that is something important to tell the OpenSSH people about!

I'm sure they already know about it.

I'm not using those cmdlets, I'm just using standard ssh sessions. So, no that is what seem to be broken then.

Then the problem isn't PowerShell but something in Win32-OpenSSH and you should direct your questions there. This repo can't do anything to help you with this unfortunately.

Answer 6 · 2020-10-07T07:07:48.000Z

Then the problem isn't PowerShell but something in Win32-OpenSSH and you should direct your questions there. This repo can't do anything to help you with this unfortunately.

They were the ones telling me to come here... 🇷🇺 🏃 🥇

Answer 7 · 2020-10-07T08:24:50.000Z

I can replicate the problem but there's a few things that need to be cleared up. There are 3 main types of SSH methods when it comes to SSH on Windows:

When you call ssh user@host you are creating an interactive logon
When you call ssh user@host 'command to run' you are creating a non-interactive logon to run an individual command
When you call Enter-PSSession or Invoke-Command with the -HostName in PowerShell you are creating a PSRemoting session through the PowerShell subsystem

For my testing I've set the following reg keys

Set-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Program Files\PowerShell\7\pwsh.exe"
Set-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShellCommandOption -Value "-NoLogo -Command"

The first is simple, the sshd service will start a new process that is set to call C:\Windows\System32\cmd.exe by default or whatever DefaultShell is set at. In this example I simply called ssh username@hostname and I can see that sshd.exe will spawn the pwsh process based on what I have set in DefaultShell.

I did find that the value of DefaultShellCommandOption is ignored here, it seems like only DefaultShell is used for this type of logon.

When I run ssh username@hostname Start-Sleep -Seconds 60 this is the process tree

The command line here is "C:\program files\powershell\7\pwsh.exe" -c "Start-Sleep -Seconds 60" which is not what I have specified in DefaultShellCommandOption. This is entirely outside of PowerShell's realm, the sshd.exe service is ignoring the value here

Finally when I run Enter-PSSession -HostName hostname this is the process tree

We can see that our Subsystem entry was used and started the value that was in your sshd_config. This is because PowerShell does not use a naked SSH session but rather an SSH subsystem to read and write bytes directly to that pwsh -sshs process. This is done specifically for PSRemoting which doesn't operate like a normal process but rather with an exchange of PowerShell specific packets.

Putting it all together PowerShell is doing nothing here that isn't expected. It's been told to start normally which it does so. The issue lies in the Win32-OpenSSH software as that isn't using the DefaultShellCommandOption option that is configured. This must be fixed there as there is nothing the PowerShell team can do. ~~It may even already be fixed in a newer release of Win32-OpenSSH, I know the one that is included in Windows is quite old~~ (scratch that, I just tested the latest GitHub release and it's still an issue).

Answer 8 · 2020-10-07T14:15:01.000Z

OT side note:

~~It may even already be fixed in a newer release of Win32-OpenSSH, I know the one that is included in Windows is quite old~~ (scratch that, I just tested the latest GitHub release and it's still an issue).

I also just tried to install the latest available release (8.1.0) of Win32-OpenSSH according their instructions and that broke my SSH server access. (I can only login from local host, but remote host just keep timing out and DEBUG3 doesn't show anything at all. 👎

- UPDATE

Although it should have been obvious, I did not "uninstall" the old out-of-the-box OpenSSH before trying the new one. Apparently it took over some ports or services and messed with the new one. As soon as I removed those client/server packages it worked again as before. I wish there were some better log messages about this. (There were none.)

Answer 9 · 2020-10-07T14:30:54.000Z

@eabase

I just finishing getting my refurbished laptop ready. So, I will try my ssh components.
Although, I'm on Windows 10 Pro, and I never recall adding registry keys to make this work. I have a series of blog posts (www.maxtblog.com) where I show how to setup SSH to work work with PowerShell Core (at that time), but I need to verify this using the latest version of PowerShell (v7.0.3, and Preview).

I will get back to this issue later.

Answer 10 · 2020-10-08T19:00:05.000Z

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

Answer 11 · 2020-10-08T20:10:35.000Z

Yes, PowerShell ignores these two switches when started as an SSH remoting server. Runspace initialization is performed in a different path in this case.

The switches are only necessary to ensure the session is started as a server session.

Answer 12 · 2020-10-13T16:39:53.000Z

@PaulHigin

...ignores these two switches when started as an SSH remoting server...The switches are only necessary to ensure the session is started as a server session.

Can you clarify what you just said? (Sound contradictory to me.)

Runspace initialization is performed in a different path in this case.

Where is that?

Maybe you can forward this info to the Win32-OpenSSH devs?

Answer 13 · 2020-10-14T16:35:12.000Z

Sorry for the confusion. If you look at PowerShell start up code, it has morphed over the years with various options and code paths. In order to start up in server mode these switches are necessary to go down the right code path. This can definitely be cleaned up, but since it is not a common operation, it is not high priority.

Remoting runspace initialization is done in response to a PSRP session creation message. Initialization is configurable:
https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/remoting/fanin/InitialSessionStateProvider.cs
But this is currently only supported in WinRM remoting. PowerShell SSH remoting currently just initializes the runspace as default, but will eventually be configurable similar to WinRM.

This has nothing to do with Win32-OpenSSH so I see no reason to inform them.

GitHub
PowerShell/PowerShell
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.