I agree with @slm that this is something of a borderline question. The truth is, Windows incorporates its own remote access protocols as your Unix system incorporates its own. Microsoft Powershell has matured a great deal since it was introduced with Vista, and it can do most if not all of the things you'd expect a shell script to do for you on your Windows system. For instance, according to technet:
The Windows PowerShell remoting features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows. Computers running Windows 7 and later include WinRM 2.0 or later. On computers running earlier versions of Windows, you need to install WinRM 2.0 or later as appropriate and if supported. Currently, remoting is supported on Windows Vista with Service Pack 1 or later, Windows 7, Windows Server 2008, and Windows Server 2008 Release 2.
Of course making use of this from a Linux client presents some problems, but I expect a virtual machine would solve most of them, or even just a netcat
or ssh
proxy. Contributing 5 minutes and the use of a search engine to my mild curiosity and I now know of the Pash project, though I will make no claims on its usefulness.
UPDATE:
In the course of once again entertaining that mild-curiosity I revisited the Pash sourceforge page
and browsed just a little more. While doing so, I noticed that the associated RECOMMENDED PROJECTS included not only the winexe
that @slm recommends, but another I'd never heard of called win-bash
. From the description:
Unlike other bash
ports for Windows (e.g. the cygwin bash
), the win-bash
needs no special environment or DLLs. There is just one binary and that's it.
The goal of the win-bash
project is to finish the port to Windows and provide a fully-functional bash.exe
binary for Windows NT and derived systems. win-bash
can be used as an input shell, as well as an interpreter to run UN*X shell scripts.
What I find significant about the above regarding this question is its standalone nature. If it has no library or registry dependencies, a Windows executable can be remotely executed - for instance from a file share - without installation. So it is conceivable that you could remote into a machine using native Windows protocols (possibly also with or including winexe
), run a powershell
or net use
command to map a file share, execute your shell script via win-bash,
then unmap the share and terminate the connection without having to copy even a single file to the remote host.
I say it is conceivable, but does it work? I don't know, though I might just find out.
I like to keep a current win pe image on my system's EFI partition so it is available to rEFInd
(and bootable thanks to an iPXE
hack or two). So far I've only customized it to block the default Windows install starting and set it to open a cmd
prompt proxied by netcat,
because cygwin
seemed to me to be an awful lot of chore for little return, but now my previously mild curiosity is growing... I'll likely return with a report on my experience afters adding it to my pe image.
END UPDATE
@slm mentions winexe
, of which I had never heard before, though I am now interested. He also mentions wmic
as a tool you can use, and that is a tool which I have often used myself - it grants you pretty powerful access to the Registry backend using SQL-like syntax.
I do know that if you wish to execute .cmd
scripts based on specific rules there is the Windows Task Manager and Windows Group Policy, both of which, as I believe, you can influence at least to some degree via wmic.
Last I will say that porting code from one operating system to another is not done as often as we might like for a reason: it is problematic by its very nature. Different operating systems behave differently, if nothing else, at the least because they are different. ssh
for instance, at least in my experience, was incapable of handling Windows' graduated permissions and required either system level access or simply did not work, though netcat
seemed to accept the permissions level of the user account under which I ran it. Powershell, as I mentioned above, can be an extremely tedious tool if used for parsing strings, as you may be accustomed to do in a Unix environment, because it treats everything as an object in its own right. So good luck.
wmiexe
, for eg.:winexe -U "<user>%<pwd>" //192.168.1.2 'wmic bios get serialnumber'
winexe ...some remote server + script call...
would easily do the job and be easier to maintain.