PowerShell: Users with a profile which outputs anything cannot create PSSessions over SSH

Prerequisites

Steps to reproduce

  1. If OpenSSHD is not already present, install it (e.g. on Windows run Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0)
  2. Enable Remote sessions over ssh by editing the sshd config file as described in https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ssh-remoting-in-powershell-core?view=powershell-7.2 (on Windows copy C:\Windows\System32\OpenSSH\sshd_config_default to C:\ProgramData\ssh\sshd_config to give yourself a file to start from)
  3. Backup your profile.ps1 if you have one, and create a simple profile.ps1 e.g. 'hello'
  4. run new-PSSession -HostName localhost
  5. Observe the error New-PSSession: [localhost] There is an error processing data from the background process. Error reported: Hello.
  6. Think “A-ha I need to use -NoProfile so SSH works like WinRM”, modify the config file, restart the sshd Service, try again, curse when the same error occurs

Expected behavior

PS>  new-PSSession  -HostName localhost
xxxx@localhost's password:

 Id Name            Transport ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            --------- ------------    ------------    -----         -----------------     ------------
  5 Runspace4       SSH       localhost       RemoteMachine   Opened        DefaultShell             Available

Actual behavior

PS>  new-PSSession  -HostName localhost
xxxx@localhost's password:
New-PSSession: [localhost] There is an error processing data from the background process. Error reported: Hello.

Error details

New-PSSession: [localhost] There is an error processing data from the background process. Error reported: Hello.

Environment data

PS>  $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.0-preview.7
PSEdition                      Core
GitCommitId                    7.3.0-preview.7
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

image

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

@237dmitry It’s not the prompt. image

Just connecting using SSH with pwsh set as the default shell for sshd is fine. There are two things with PSSessions

  1. A PSSession over WSMan does not process the profile. The command to start pwsh in an ssh subsystem Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs ... does.
  2. Any output form subsystem at start up seems to cause an error

I think (2) is expected with openssh -if you don’t specify -NoLogo in the subsystem you get an error citing the the PowerShell version message (The way I have installed 7.3 preview means I can’t test on that - the help I linked to above says the -NoLogo isn’t needed in 7.3, so this symptom may have been silently fixed)

But (1)… PSSessions should do the same things regardless of the connection mechanism. But the -sshs switch doesn’t do that automatically and causes -NoProfile to be ignored unless someone tells me that has also changed for 7.3

It seems that if the user is a member of admins, ssh connections are always as admin. Since I’m testing on my local machine I’m using New-PSSession -EnableNetworkAccess -ComputerName localhost for winrm, and I think that inherits the token from the current session because if I connect from PowerShell run as admin, my PSSession returns true for [System.Security.Principal.WindowsIdentity]::GetCurrent().Groups.Value -contains 'S-1-5-32-544' and if I run from PowerShell un-elevated, it returns false. AIUI this is specific to -EnableNetworkAccess not to winrm so the should in “PSSessions should do the same things regardless of the connection mechanism.” is not a must

@jhoneill Sorry, got confused because the title says SSH