Some thoughts on remote controlling multiple Windows PCs

There are multiple components to this problem. At least four parts:

Some sort of mechanism to communicate/command remote computers
Some scripting engine on the 'boss'
Some mechanism for file transfer (to retrieve log files etc)
Some remote software

1. Communicating with remote computers

I've had some success using FreeSSHD. It creates an SSH server on a Windows box, with simple login/authentication, and can be run as a Windows service. Points to consider

Security might be an issue. This software is written seemingly on the assumption that if you can log into a computer, you can do whatever you want with it. Unfortunately they extend the priviledge to non-admin users... but here's a possible solution:
- After installation, the server needs to be run from its shortcut, and configured as appropriate. It can be set up to only listen on a particular IP address, which is nice, but I don't know how well that will deploy in the lab image..?
- Once the program is configured, run services.msc and find freeSSHDService. Modify it to run Automatic (might be default anyway?) and change its properties so it can't interact with desktop. (This will stop the tray icon from appearing).
  - One downside of this is that it seems you can't point it to powershell as the default command prompt unless you have desktop interaction enabled. Might still be able to run powershell by typing powershell from cmd.exe - shell inside a shell!
- Start the service either in the services panel or by typing net start freeSSHDService. If the program is run from the icon and then quit, this will stop the service again (which is a bit annoying).
- Non-admin logins shouldn't have any access (no read or write) to C:\Program Files\FreeSSHD\ (or wherever it's installed). The service is run as System (an admin super-user) by default so it will still work properly... but you don't want non-admins from being able to manually run the program and disrupt things. This also means that remote logins are running with System rights, which is probably bad : it might be worth looking at how hard it is to use something better than basic password authentication (freesshd seems to support a bunch of methods).
- Another idea would be create a specific user for SSH logins with limited access to most of the computer, but read/write access to the program folder. Then, by running the service with that user's login you could limit potential havoc wreaked by dodgy remote logins.
An alternative is Windows Open SSH, which is an implementation of Open SSH+just enough Cygwin to get it working. I could install the service and everything, but I didn't understand the authentication scheme so I couldn't log in. On the bright side, it looks like it would run silently if it worked (although with the precautions listed above, freeSSHD is OK).

Communication can be achieved using putty or any other SSH client tool. A command line version of putty is available: plink. This lets you run commands on a remote computer and intercept the output at your own prompt.

2. Master scripting engine

The 'boss' computer needs to be able to run some script that sends commands to a whole bunch of computers. powershell is an obvious choice for this. A wrapper can be written for plink to turn it into a semi-native powershell command (do some googling). http://halr9000.com/article/450 has a good example of this (Invoke-QaSshCmd computername command). So, it's likely that the 'boss' PC would run powershell, and the lab pcs run freeSSHD servers but utilise the standard cmd.exe prompt (they don't need local scripting).

3. File transfer

Freeftpd is a sister project to freesshd and looks like it would let you run a server with SFTP login or similar. PSFTP is a command line program by the author of putty that can login to SFTP servers, and using the -b switch can run a batch of commands (i.e.: login, change remotedir to log files, change localdir to storage, retrieve logfiles, disconnect).

4. Remote software

The remote software can be whatever you want, as long as it runs at the command line and can log to disk to some SFTP accessible location. It would probably be handy to add the program's location to the windows PATH variable, so that you don't have to muck around finding it when you log in remotely before running it.

-- DavidMcKechnie - 10 Feb 2009

Topic RemoteControlOfMultipleWindowsPCs . { Edit | Attach | Ref-By | Printable | Diffs | r1.2 | > | r1.1 | More }

Revision r1.2 - 10 Feb 2009 - 22:49 GMT - DavidMcKechnie Parents: WebHome > PacketRadio	Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback.

	TWiki > WSensornets > PacketRadio > RemoteControlOfMultipleWindowsPCs	TWiki webs: Main \| TWiki \| Know \| Sandbox
	WSensornets . { Changes \| Index \| Search \| Go }