When an SSH remoting session is created the server doesn't seem to redirect the stdout pipe to nothing so anything that writes to stdout is picked up and treated as a PSRP fragment from the server. Because these fragments are designed in a particular way and should come in sequence it's pretty much going to crash the process because the client cannot treat the message as a PSRP response.
Funnily enough the server mode setup with -s sets the Stdout/Stderr/Stdin streams to TextWriter.Null alleviating this problem
|
private OutOfProcessMediator() : base(true) |
|
{ |
|
// Create input stream reader from Console standard input stream. |
|
// We don't use the provided Console.In TextReader because it can have |
|
// an incorrect encoding, e.g., Hyper-V Container console where the |
|
// TextReader has incorrect default console encoding instead of the actual |
|
// stream encoding. This way the stream encoding is determined by the |
|
// stream BOM as needed. |
|
originalStdIn = new StreamReader(Console.OpenStandardInput(), true); |
|
|
|
// replacing StdIn with Null so that no other app messes with the |
|
// original stream. |
|
Console.SetIn(TextReader.Null); |
|
|
|
// replacing StdOut with Null so that no other app messes with the |
|
// original stream |
|
originalStdOut = new OutOfProcessTextWriter(Console.Out); |
|
Console.SetOut(TextWriter.Null); |
|
|
|
// replacing StdErr with Null so that no other app messes with the |
|
// original stream |
|
originalStdErr = new OutOfProcessTextWriter(Console.Error); |
|
Console.SetError(TextWriter.Null); |
|
} |
.
The SSH server mode -sshs only gets the handles to write to without setting the existing console handles to Null causing this problem
|
private SSHProcessMediator() : base(true) |
|
{ |
|
#if !UNIX |
|
var inputHandle = PlatformInvokes.GetStdHandle((uint)PlatformInvokes.StandardHandleId.Input); |
|
originalStdIn = new StreamReader( |
|
new FileStream(new SafeFileHandle(inputHandle, false), FileAccess.Read)); |
|
|
|
var outputHandle = PlatformInvokes.GetStdHandle((uint)PlatformInvokes.StandardHandleId.Output); |
|
originalStdOut = new OutOfProcessTextWriter( |
|
new StreamWriter( |
|
new FileStream(new SafeFileHandle(outputHandle, false), FileAccess.Write))); |
|
|
|
var errorHandle = PlatformInvokes.GetStdHandle((uint)PlatformInvokes.StandardHandleId.Error); |
|
originalStdErr = new OutOfProcessTextWriter( |
|
new StreamWriter( |
|
new FileStream(new SafeFileHandle(errorHandle, false), FileAccess.Write))); |
|
#else |
|
originalStdIn = new StreamReader(Console.OpenStandardInput(), true); |
|
originalStdOut = new OutOfProcessTextWriter( |
|
new StreamWriter(Console.OpenStandardOutput())); |
|
originalStdErr = new OutOfProcessTextWriter( |
|
new StreamWriter(Console.OpenStandardError())); |
|
#endif |
|
} |
.
Steps to reproduce
Enter-PSSession -HostName windows
[Console]::WriteLine('boom')Expected behavior
No output as the raw stdout console should not be attached to anything just like a WSMan remoting session.
This at least aligns with WSMan based sessions and I assume pwsh -s ones as there is no console attached for WSMan and -s sets the stdio streams in .NET to TextWriter.Null. In reality it would be nice if anything written to raw stdout would translate to $host.UI.Write() but that would be a future enhance IMO.
Actual behavior
Errors with the following and the session is closed
There is an error processing data from the background process. Error reported: boom.
Environment data
Name Value
---- -----
PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Microsoft Windows 10.0.17763
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
When an SSH remoting session is created the server doesn't seem to redirect the stdout pipe to nothing so anything that writes to stdout is picked up and treated as a PSRP fragment from the server. Because these fragments are designed in a particular way and should come in sequence it's pretty much going to crash the process because the client cannot treat the message as a PSRP response.
Funnily enough the server mode setup with
-ssets the Stdout/Stderr/Stdin streams toTextWriter.Nullalleviating this problemPowerShell/src/System.Management.Automation/engine/remoting/server/OutOfProcServerMediator.cs
Lines 459 to 482 in 99a49e0
The SSH server mode
-sshsonly gets the handles to write to without setting the existing console handles toNullcausing this problemPowerShell/src/System.Management.Automation/engine/remoting/server/OutOfProcServerMediator.cs
Lines 526 to 549 in 99a49e0
Steps to reproduce
Expected behavior
No output as the raw stdout console should not be attached to anything just like a WSMan remoting session.
This at least aligns with WSMan based sessions and I assume
pwsh -sones as there is no console attached for WSMan and-ssets the stdio streams in .NET toTextWriter.Null. In reality it would be nice if anything written to raw stdout would translate to$host.UI.Write()but that would be a future enhance IMO.Actual behavior
Errors with the following and the session is closed
Environment data