Broken authorization of standard SSH public keys on Windows

[lukasfazik]

Description
The function authorizeSSHKeyStandard() in context.ps1 (context-windows) uses $env:USERPROFILE variable when storing the user's public key. Because the contextualization service runs as a local system account, the resulting value for this environment variable is C:\WINDOWS\system32\config\systemprofile\, which is not expected behavior.

Also, the function uses .ssh folder instead of authorized_keys file when calling Set-Content cmdlet to write the public keys into a file. This operation fails.

To Reproduce

• Prepare Windows virtual machine
• Install OpenNebula context
• Add public SSH key into context
• Add WINADMIN = "NO" context variable
• Wait 30+ seconds for context to run and pick up the changes
• See that context portion for setting the SSH key fails and no authorized_keys file is created

Expected behavior
The USERNAME context variable should be used instead (like in context-linux). Also, a check should be performed to see if the user profile exists before forcefully creating .ssh directory. This avoids messing up the permissions for the future user profile directory.

Details

• Affected Component: context-windows
• Version: 6.10.0-2

Additional context

• OpenNebula context log representing the issue: opennebula-context.log
• Windows has a default setting for SSH Service that all users belonging to the Administrators group share the authorized SSH keys from %PROGRAMDATA%\ssh\admin_authorized_keys. So this feature needs to be disabled when WINADMIN = "NO" since context adds the user in USERNAME context variable to the Administrators group.
• Microsoft docs for SSH in Windows

Progress Status

• Code committed
• Testing - QA
• Documentation (Release notes - resolved issues, compatibility, known issues)