In Windows, we can get environment variables by $env:{VARIABLE_NAME}. If the variable contains other variables, which is commonplace in PATH, like %WINDIR%\System32, this command will print the evaluated result, like C:\Windows\System32 for the previous example. This is done during shell startup, I suppose.
But inconsistency occurs when it comes to SSH server.
I recently installed pnpm, a high-performance alternative to npm, on my Windows server. It is installed to %LocalAppData%, and it adds its program root to user-level PATH by referring to PNPM_HOME, another user-level variable it creates. When I tried to call pnpm from the remote SSH session, it failed to be resolved. Then I ran $env:PATH in the session, and received the following output:
...;$PNPM_HOME$;...
The referred environment variable failed to be evaluated, while everything goes as expected running the same command on my server through remote desktop.
I looked into corresponding documents, and propounded a plausible explanation: All Windows services are run by the user SYSTEM, and so is the SSH server. When an SSH tunnel establishes, the SSH server reads the registry and evaluated embedded environment variables under the context of itself instead of the remote user. SYSTEM has no PNPM_HOME, thus this PATH segment fails to be evaluated, then the problem ensues.
To corroborate my presumption, I added a new segment $USERNAME$ to PATH, which got evaluated as 'SYSTEM' in the SSH session.
Now, here's my question: how to resolve this problem without changing the environment variables, if my assumption is proven; If not, what's the actual cause of this problem?
By the way, should this be submitted as a bug to OpenSSH?