Skip to content

Conversation

@PaulHigin
Copy link
Contributor

A recent change in Win32-OpenSSH caused PowerShell SSH remoting to break when targeting a Windows machine (Windows->Windows or Linux->Windows). The breaking change in Win32-OpenSSH is that when it creates a subsystem process it no longer creates a console for that process, since a console is not needed.

However, PowerShell currently requires a process console even when it is running in server mode when a console is not really needed.

The fix is to update PowerShell so that it does not require a process console when it is running in server mode. It includes removing unused fields in the CommandLineParameterParser class and only failing on start up with a console error when running in console mode.

@msftclas
Copy link

Hi @PaulHigin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!


It looks like you're a Microsoft contributor (Paul Higinbotham). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@PaulHigin PaulHigin added WG-Remoting PSRP issues with any transport layer and removed cla-not-required labels Oct 26, 2016
@PaulHigin PaulHigin added this to the 6.0.0-alpha.12 milestone Oct 26, 2016
_parent = p;
_ui = (ConsoleHostUserInterface)p.UI;
_ver = ver;
_ui = (p != null) ? (ConsoleHostUserInterface)p.UI : null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For better future-proofing, maybe we should provide a dummy ConsoleHostUserInterface implementation that does nothing. This would also avoid many of the other changes.

@PaulHigin
Copy link
Contributor Author

Updated PR based on comments.

@mirichmo mirichmo self-assigned this Oct 27, 2016
_ui.WriteToConsole("Waiting - type enter to continue:", false);
_ui.ReadLine();
((ConsoleHostUserInterface)_hostUI).WriteToConsole("Waiting - type enter to continue:", false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about when _hostUI is a NullHostUserInterface?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then this will fail. Note that this is for debugging interactive console only and should never be called without ConsoleHostUserInterface.


In reply to: 85439307 [](ancestors = 85439307)

try
{
args = new string[0];
s_theConsoleHost = ConsoleHost.CreateSingletonInstance(configuration);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be within the try-finally on line 222 since the finally conditionally disposes it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because otherwise CommandLineParameterParser will never be called and we can't find out if we are running server mode where s_theConsoleHost is not needed. Also I am saving the HostException so I can re-throw if it turns out we are not running in server mode.


In reply to: 85440668 [](ancestors = 85440668)

{
TelemetryAPI.ReportExitTelemetry(s_theConsoleHost);
s_theConsoleHost.Dispose();
if (s_theConsoleHost != null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check seems a bit unnecessary. ConsoleHost.CreateSingletonInstance asserts (in debug mode) that it is non-null

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the exact condition I am allowing. The s_theConsoleHost is null because the process is created without a console, but that is Ok if we are running in server mode. If we are not running in server mode then the HostException is re-thrown since interactive PowerShell requires s_theConsoleHost.

I liked my original changes over this second iteration because it was cleaner. The command line is parsed and if we run in server mode we don't even bother creating the s_theConsoleHost. But that version was rejected.


In reply to: 85441248 [](ancestors = 85441248)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't realize your changes were all in the command line parser.

Maybe a better fix is to just use the Console apis directly.

I guess in server mode you should never see an error, but you'd want the error reported if there was one, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume System.Console APIs won't work if there is no process console. However, I can use the ConsoleHost class tracer to write errors. But I don't feel that reporting a command line parse error in this case is very important.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Console.Out.Write shouldn't cause any problems.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This always confuses me. Isn't this the console std out? If so then again I presume it is not available when no process console is available. In any case it seems that trace output would be better for debugging a rare case of command line errors in server mode.

@mirichmo mirichmo merged commit 24f3b75 into PowerShell:master Nov 1, 2016
@PaulHigin PaulHigin deleted the W32OpenSSHFix branch November 17, 2016 19:14
@iSazonov iSazonov mentioned this pull request Oct 1, 2018
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WG-Remoting PSRP issues with any transport layer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants