Win32-OpenSSH doesn't recognize WinRM Virtual Users

[jootuom]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

I want to run ssh-keygen inside a PowerShell JEA session running under a virtual account to manage SSH certificates. Unfortunately many of the ssh commands want to convert a UID to username even when it would not strictly be required - ssh-keygen being one of them. This fails when running under a virtual account.

Expected behavior

PS> ssh-keygen.exe -s C:\\ca -I "<user>" -n root C:\\user.pub
Signed user key user-cert.pub: id "<user>" serial 0 for root valid forever

Actual behavior

# JEA session configuration:
PS> Get-Content myjea.pssc
...
RunAsVirtualAccount = $true
...

# inside JEA session:
PS> whoami.exe
winrm virtual users\winrm va_11_<domain>_<user>

# run a custom JEA command:
PS> New-SSHCertificate ...
# which would run behind the scenes:
# ssh-keygen.exe -s C:\\ca -I "<user>" -n root C:\\user.pub
# result:
No user exists for uid 1

Error details

Environment data

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Microsoft Windows 10.0.20348
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

7.5.4

Visuals

No response

[jborean93]

It looks like ssh-keygen emits the error No user exists for uid 1 at

https://github.com/PowerShell/openssh-portable/blob/745466fbfcf9617f198793e5eab22ad408ba21f4/ssh-keygen.c#L3471-L3473

The Win32 implementation of getuid() is harded to return 1 in w32_getuid() which explains why the uid in the error is 1. The getpwuid() method is returning null which is causing the fatal call.

If we look at w32_getpwuid() it does two things, gets the SID of the current user then builds the passwd structure from that information.

https://github.com/PowerShell/openssh-portable/blob/745466fbfcf9617f198793e5eab22ad408ba21f4/contrib/win32/win32compat/pwd.c#L380-L396

Either one of those two could be failing to resolve things like a virtual account SID, expecting a profile to be present, or expecting a profile to be present. I think the simplest solution would be to just step through the code or do the checks manually to see what fails and what works. I may have some time next week to look through but cannot give any guarantees.

[jborean93]

Looks like the issue is due to the length of the domain name portion of the virtual user exceeding 15 characters. The call to LookupAccountSidW is failing because domain_name_size is only 16 (DNLEN is defined as 15 in the SDK headers).

https://github.com/PowerShell/openssh-portable/blob/745466fbfcf9617f198793e5eab22ad408ba21f4/contrib/win32/win32compat/pwd.c#L229-L237

Because the buffer size is too small LookupAccountSidW fails which in turn has the program exiting early. We can see in the output shared by OP that the domain name for WinRM Virtual Users is winrm virtual users which is 19 characters (20 with the null char) exceeding the DNLEN. When building ssh-keygen with a larger value for the domain name I was able to get it to continue. I'm not sure what the default value should be here or whether the code should change to calculate the buffer first then call it again after creating a buffer of that size, that'll be up to the maintainers of this program.

One thing to note is that the default profile path will be C:\Windows for this account as the virtual account will have no profile set in the registry and ssh-keygen defaults to C:\Windows in that case

https://github.com/PowerShell/openssh-portable/blob/745466fbfcf9617f198793e5eab22ad408ba21f4/contrib/win32/win32compat/pwd.c#L267-L276

Finally while this can now run with these changes, running a binary with interactive prompts in Enter-PSSession is not going to work as expected. This is a limitation on PSRemoting and not something this program can deal with. You'll have to make sure that your ssh-keygen.exe call uses the right arguments that makes it run non-interactively otherwise it will fail.