-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Fix for PowerShell SSH remoting with recent Win32-OpenSSH change. #2538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… an SSH subsystem.
|
Hi @PaulHigin, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
TTYL, MSBOT; |
| _parent = p; | ||
| _ui = (ConsoleHostUserInterface)p.UI; | ||
| _ver = ver; | ||
| _ui = (p != null) ? (ConsoleHostUserInterface)p.UI : null; |
There was a problem hiding this comment.
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.
|
Updated PR based on comments. |
| _ui.WriteToConsole("Waiting - type enter to continue:", false); | ||
| _ui.ReadLine(); | ||
| ((ConsoleHostUserInterface)_hostUI).WriteToConsole("Waiting - type enter to continue:", false); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.