Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a difficult time coming up with a solution to extend a framework that was designed for *nix machines over to windows. The framework currently runs from one *nix server and ssh's out to other *nix servers and performs a bunch of different commands like checking log files, syncing files from source control, submitting logs back to source control, etc. The big piece I'm stuck on is how to connect to the remote windows machines and access the command line. The connection can be coming from another Windows machine also, it doesn't have to start from a unix machine, it can go from windows to windows instead of unix to windows.

Here's an example of how commands are currently ran on unix systems. Something like this is in a loop that goes through a list of server names. I need to get something like this to run on windows machines.

ssh ${user}@${server} "cd /app/app_name/logs; <export source control params>; <submit logs to source control>" >> Log.txt

Also, I would prefer not to use a 3rd party tool (my budget is about $0). I've checked out PsExec and a couple others but it looks like you need admin access or have to pass users/pass in plain text.

share|improve this question

migrated from Sep 6 '11 at 8:31

This question came from our site for professional and enthusiast programmers.

By design, a non-administrative user can't normally run code on a remote machine. You might have to build your own solution. Is there a specific context the code needs to run in? Are the commands to be run the same every time? – Harry Johnston Sep 6 '11 at 4:40
While you could install MobaSSH as a server and use putty as a client, or use psexec to do whatever you want more or less (which is frowned upon in my experience), the equivalent idiom in the Windows world is not to use a shell at all, but to rely on command level support for remote execution whether it's a legacy command or powershell combined with network shares and mapped drives. – novaterata Jun 7 at 20:02

Try tunnellier from Bitvise. That is an ssh client. There's also an ssh server for connecting to a windows machine. The two enable you to make very secure connections along with more advanced things like a web proxy or port tunneling.

share|improve this answer
Unfortunately the SSH server isn't freeware. – Harry Johnston Sep 6 '11 at 4:34

You could try psexec which gives you a remote shell over the file share service (or however this is called). There is also winexe if you want to use Linux as client.

share|improve this answer

Install OpenSSH port for Windows - it's free and provides both client and server.

share|improve this answer
There are security issues, though - because it uses Cygwin, it isn't multiple-user safe. (Unless my information is out of date?) – Harry Johnston Sep 6 '11 at 7:46

PuTTY is also a popular Windows SSH Client.

share|improve this answer
Wouldn't you need an SSH server for this, not just a client? – Ajedi32 Jul 17 '15 at 18:49
This does not answer the question. He's looking for a server-client combination – guidod Oct 30 '15 at 12:40

Use Powershell Remoting:

Shamelessly copy-pasted:

Windows PowerShell Remoting

Windows PowerShell remoting, which uses the WS-Management protocol, lets you run any Windows PowerShell command on one or many remote computers. It lets you establish persistent connections, start 1:1 interactive sessions, and run scripts on multiple computers. To use Windows PowerShell remoting, the remote computer must be configured for remote management. After you have configured Windows PowerShell remoting, many remoting strategies are available to you. The remainder of this document lists just a few of them.

Start an Interactive Session

To start an interactive session with a single remote computer, use the Enter-PSSession cmdlet. For example, to start an interactive session with the Server01 remote computer, type: enter-pssession Server01 The command prompt changes to display the name of the computer to which you are connected. From then on, any commands that you type at the prompt run on the remote computer and the results are displayed on the local computer.

To end the interactive session, type: exit-pssession

Run a Remote Command

To run any command on one or many remote computers, use the Invoke-Command cmdlet. For example, to run a Get-UICulture command on the Server01 and Server02 remote computers, type:

invoke-command -computername Server01, Server02 {get-UICulture}

The output is returned to your computer.

LCID    Name     DisplayName               PSComputerName
----    ----     -----------               --------------
1033    en-US    English (United States)
1033    en-US    English (United States)

Run a Script

To run a script on one or many remote computers, use the FilePath parameter of the Invoke-Command cmdlet. The script must be on or accessible to your local computer. The results are returned to your local computer.

For example, the following command runs the DiskCollect.ps1 script on the Server01 and Server02 remote computers.

invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1

Establish a Persistent Connection

To run a series of related commands that share data, create a session on the remote computer and then use the Invoke-Command cmdlet to run commands in the session that you create. To create a remote session, use the New-PSSession cmdlet.

For example, the following command creates a remote session on the Server01 computer and another remote session on the Server02 computer. It saves the session objects in the $s variable.

$s = new-pssession -computername Server01, Server02

Now that the sessions are established, you can run any command in them. And because the sessions are persistent, you can collect data in one command and use it in a subsequent command.

For example, the following command runs a Get-Hotfix command in the sessions in the $s variable and it saves the results in the $h variable. The $h variable is created in each of the sessions in $s, but it does not exist in the local session.

invoke-command -session $s {$h = get-hotfix}

Now you can use the data in the $h variable in subsequent commands, such as the following one. The results are displayed on the local computer.

invoke-command -session $s {$h | where {$_.installedby -ne "NTAUTHORITY\SYSTEM"} }
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.