Trouble is, this process (ssh.exe) never completes. If I run the same System.Diagnostics.ProcessStartInfo object from a remote PSSession, or via PS console on the machine, it executes (and completes) fine.
I’ve taken a look at the process started by PSU (failing) and one started manually (working) using Get-CimInstance Win32_Process, but cannot for the life of me see any difference between the two.
If anyone has any ideas/pointers for where I can take this, or further debugging I could try, I’d be very grateful!
It doesn’t seem to make any difference which environment I choose: Integrated (parent process being universal.server), Windows PoSH 5.x (powershell.exe), Core 7.1.3 (pwsh.exe), the ssh process starts and only stops if I intervene to stop it.
I’ve run the same piece of code logged on to the console locally and via remote PSSession in both Windows PoSH 5.x and Core 7.1.3 and it succeeds without a hitch. It’s a real head-scratcher.
As an update this morning, I tried encapsulating the process using cmd /c (using a System.Diagnostics.ProcessStartInfo object) but the ssh.exe process failed to terminate again, meaning that the cmd.exe process didn’t terminate either.
This starts ssh.exe on my PSU server, but again it fails to terminate and never returns anything to the $output variable.
Can anyone suggest a way to ‘break free’ of the dashboard process as a parent so that I can test if ssh behaves differently that way?
As previously mentioned (and in this latter test using New-PSSession) I’ve used the same code successfully inside a console pwsh process.
Could this have to do with ssh prompting for a password? I can certainly reproduce this and I don’t have keys configured for the server\client. I do not see the output from ssh prompting for the password at all when running in PSU. Inside a PS console, it prompts fine.
Are you running PSU as the same account as when you are trying it locally? I’m not an SSH expert but I think when you generate the keys that get installed to the current user account so just verifying that it’s running as the same user.
That’s a very good point, Universal.Server would be running as NT AUTHORITY\SYSTEM.
I can test using username/password on a box that supports that, which should eliminate the running user. If that works, I will need to test again after generating a key pair under the Local System account!