Allow Use Of Non-ASCII Character In SSH Client Passwords

[NoMoreFood]

• Modified readpassphrase() to read unicode characters and return utf8-encoded password strings to allow use of non-ascii characters.

Addresses: PowerShell/Win32-OpenSSH#1178
May be related to: PowerShell/Win32-OpenSSH#1084

[manojampalam]

I've been longing to rewrite this logic for a while.
My proposal is to do the following:

1. Save current console settings
2. Modify console settings to echo off and line mode (SetConsoleMode(ENABLE_LINE_INPUT)
3. ReadFile(CONIN)
4. Revert console settings

Thoughts?

[NoMoreFood]

Topically, I think that could work although messing with console mode can sometimes have some unforeseen consequences. I haven't written many console programs that dynamically ask for input so I don't have a strong knowledge base about what those might be.

The only immediate questions/concerns that come to mind are:

• Is there a possibility now or in the future that readpassphrase() could be asynchronously interrupted/ terminated thereby not allowing us to restore console settings? Update: Doesn't look like this would be a concern.
• Do we care about maintaining parity with the current code base by offering the functionality to console console behavior by manipulating/recompiling with altered RPP* constants?
• Does buffering a sensitive piece of data prior to transmission create or exacerbate any potential security concerns in terms of allowing other user mode program to capture the data?
• How does ReadFile(CONIO) respond to console input redirection scenarios? Would it behave differently from the current character-by-character processing using _getch()/_getwch()? For example, right now I can do things like echo ls / | ssh host -l user and it will ask for keyboard input for password and subsequently run ls / on the target system.

[manojampalam]

Hmm. Right. My proposal would only support a specific use case of readpassphrase and has unintended consequences. Let me review your changes.

[NoMoreFood]

@manojampalam I hadn't noticed this before, but apparently when compiling under Visual Studio 2017 vice Visual Studio 2015 (and/or against the latest Windows 10 SDK), the current readpassphrase() truncates its output to the first character. This change also happens to address that behavior and, other than setting ENABLE_PKCS11 as a processor definition, is literally the only other thing I had to do to get PKCS11 support working. Any chance to review these changes?

[manojampalam]

Apologies for the delay. I'm still looking into Unix implementation and checking how best we can support all the different modes.

[NoMoreFood]

@manojampalam Thoughts on moving forward with this?

[WSLUser]

Can we merge this in with as part of the 8.1 release? (rebase needed first)