I have a Windows server 2016 machine that needs to run an file that uses the cli, remotely using SSH.

It is known that logging out of an SSH connection terminates processes that were started by the ssh user. On linux machines, one may use solutions such as nohup or screen, resulting a process not being killed once logging off.

Such solutions won't work on windows machines though, and I'm looking for a way to prevent a process from getting terminated once logged out.

  • My client is an Ubuntu machine
  • My Windows server 2016 runs OpenSHH, with PowerShell as a default shell
  • My program is set to work in daemon mode, and no cmd or powershell windows are left open
  • Using Get-Process -Name proc_name shows the process is indeed running
  • Using Get-Process after SSH logout yields no such process

Things I also tried:

  • Running the .exe file using cmd.
  • Running a .bat and .ps files that starts the .exe with its arguments.

Is there a way to tackles this problem on a windows machine?

  • This has nothing to do with the Windows OS version. PS runs in the context of the user who started it. Killing the user kills the process. You should look to using PowerShell Background jobs.
    – postanote
    Nov 30 '20 at 22:16
  • @postanote Assuming the local user who currently runs the server is Administrator, does the SSH user (that logged in as user Administrator) considered a different user? This may explain why when logging off the connection also kills processes started by that user..
    – Pizza
    Dec 1 '20 at 7:03
  • Yes, these would be two different PowerShell sessions/instances/user contexts. If you are trying ot run PowerShell in the context of the logged-on user, Windows security boundaries prevent that. You'd need 3rdP, like Sysinternals tools or the like.
    – postanote
    Dec 1 '20 at 20:54

After spending much time digging for solutions, I found the absolute correct way of doing so using PowerShell.

It seems like it is one of those cmdlets less used or documented online, and is almost impossible to figure out on your own using the MSDN documentation, unless you're already very familiar with the huge world of Wmi Objects.

In short:

Assuming I have a program foo.exe that needs to run on background with the arguments -a, -b and bar, I should be using the exact command:

Invoke-WmiMethod -Path 'Win32_Process' -Name Create -ArgumentList 'C:\Users\foo\Desktop\foo.exe -a -b bar'

Of course if your exe is a "known" exe (either by default, such as notepad or ping) or added by you, a full path is not needed when using the -ArgumentList and exe name would be sufficient (notepad, ping, and etc..).

Additional parameters:

Invoke-WmiMethod supports additional parameters such as -Credential, -ComputerName (a good way to use a local PS to Invoke something on a remote machine without using SSH) , -Impersonation and many more documented here.

Cmdlet syntax explanation and additional cmdlet tools:

  • The -Path argument directs to a WmiObject name. There are dozens of WmiObjects, each with many Methods and Properties.
  • The -Name argument directs the used Method.
  • To list all available Wmi-Objects use Get-WmiObject -List (very difficult to locate your needed object this way).
  • To list and view all available Win32_Process Methods and Properties use
Get-WmiObject -List |where{$_.name -match '^Win32_Process$'}

This will return an output of this structure:

   NameSpace: ROOT\cimv2

Name                                Methods              Properties
----                                -------              ----------
Win32_Process                       {Create, Terminat... {Caption, CommandLine, CreationClassName, CreationDate...}

And of course using |Select-Object -ExpandProperty (_your_property_here_) will reveal all available Methods such as Create we used in the command above, and all available Properties (which we did not use).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.