Unix administration - How Can I Securely Execute Script on Remote Windows Host?

Author

How Can I Securely Execute Script on Remote Windows Host?

Will

2007-09-14, 1:30 am

What are the most secure options to allow a command line script written on
machine A to synchronously execute another command line script written on
machine B, wait on response, and retrieve return code at the end of
execution. Assume client is UNIX and server is Windows.

I need some basic encryption around the initial authentication of the client
user to the server, but could live without encryption for the rest of the
connection. Some authentication of the machines involved in the
conversation independent of user authentication (similar to SSH) would be
nice. Some ability to limit the programs that can be executed on the
target to a group of programs that have been registered in advance would be
nice.

Microsoft does have solutions like WShell and WMT, but they are based on
port 135 and DCOM. We aren't willing to open up those ports through the
firewall because too many other services get exposed on the target system
with those ports available.

There are plenty of REXEC daemons for Windows, but these appear to be
trivially written and offer no encryption to protect password traversal over
the TCP connection, no machine authentication, and do nothing to stop
execution of any arbitrary EXE on the target computer.

SSH implementations certainly cover the authentication requirements, but I
don't find a straightforward way to do a synchronous execution of a remote
EXE through the SSH pipe. I do not want to login to a remote shell and do
things manually there. I want to launch an EXE from within a client-side
script and get a return code from one command in the script that will tell
me how the program ran on the remote host after it has finished running.

What options do I have?

--
Will

Michael Vilain

2007-09-14, 7:22 pm

In article < wvCdnfMHscInlHfbnZ2dnUVZ_sOrnZ2d@giganew
s.com>,
"Will" <westes-usc@noemail.nospam> wrote:

> What are the most secure options to allow a command line script written on
> machine A to synchronously execute another command line script written on
> machine B, wait on response, and retrieve return code at the end of
> execution. Assume client is UNIX and server is Windows.
>
> I need some basic encryption around the initial authentication of the client
> user to the server, but could live without encryption for the rest of the
> connection. Some authentication of the machines involved in the
> conversation independent of user authentication (similar to SSH) would be
> nice. Some ability to limit the programs that can be executed on the
> target to a group of programs that have been registered in advance would be
> nice.
>
> Microsoft does have solutions like WShell and WMT, but they are based on
> port 135 and DCOM. We aren't willing to open up those ports through the
> firewall because too many other services get exposed on the target system
> with those ports available.
>
> There are plenty of REXEC daemons for Windows, but these appear to be
> trivially written and offer no encryption to protect password traversal over
> the TCP connection, no machine authentication, and do nothing to stop
> execution of any arbitrary EXE on the target computer.
>
> SSH implementations certainly cover the authentication requirements, but I
> don't find a straightforward way to do a synchronous execution of a remote
> EXE through the SSH pipe. I do not want to login to a remote shell and do
> things manually there. I want to launch an EXE from within a client-side
> script and get a return code from one command in the script that will tell
> me how the program ran on the remote host after it has finished running.
>
> What options do I have?

I suspect you'll have to code your own equivalent of an encrypted remote
shell if you can't find anything free or commercial on the Windows side.
You also might fair better asking in a windows group for what's
available on that platform.

Good luck.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Dave Hinz

2007-09-15, 1:38 am

On Fri, 14 Sep 2007 16:00:37 -0700, Michael Vilain <vilain@spamcop.net> wrote:

> I suspect you'll have to code your own equivalent of an encrypted remote
> shell if you can't find anything free or commercial on the Windows side.
> You also might fair better asking in a windows group for what's
> available on that platform.

A couple of thoughts. Cygwin maybe somehow? Or, some sort of a trigger
mechanism? "Hey windows box, go PULL a command from the Unix box and
run it" rather than transmitting the job as a push? Or, thinking way
out of the box, a Linux server with a Windows VM - or a Windows server
with a Linux VM. Use ssh to get the data to the Linux system on the
box, and write whatever to somewhere the Windows box can read (a shared
FAT32 filesystem for instance?)

There might be a better way. No, there's undoubtedly a better way.
But, using a vmware instance with Linux in the picture somewhere would
get you secure transport mechanism to the box, all that'd be left is to
tell the windows box to check for instructions, or to trigger it to
fetch them.

Dave Hinz

Robert Melson

2007-09-15, 1:38 am

In article < wvCdnfMHscInlHfbnZ2dnUVZ_sOrnZ2d@giganew
s.com>,
"Will" <westes-usc@noemail.nospam> writes:
> What are the most secure options to allow a command line script written on
> machine A to synchronously execute another command line script written on
> machine B, wait on response, and retrieve return code at the end of
> execution. Assume client is UNIX and server is Windows.
>
> I need some basic encryption around the initial authentication of the client
> user to the server, but could live without encryption for the rest of the
> connection. Some authentication of the machines involved in the
> conversation independent of user authentication (similar to SSH) would be
> nice. Some ability to limit the programs that can be executed on the
> target to a group of programs that have been registered in advance would be
> nice.
>
> Microsoft does have solutions like WShell and WMT, but they are based on
> port 135 and DCOM. We aren't willing to open up those ports through the
> firewall because too many other services get exposed on the target system
> with those ports available.
>
> There are plenty of REXEC daemons for Windows, but these appear to be
> trivially written and offer no encryption to protect password traversal over
> the TCP connection, no machine authentication, and do nothing to stop
> execution of any arbitrary EXE on the target computer.
>
> SSH implementations certainly cover the authentication requirements, but I
> don't find a straightforward way to do a synchronous execution of a remote
> EXE through the SSH pipe. I do not want to login to a remote shell and do
> things manually there. I want to launch an EXE from within a client-side
> script and get a return code from one command in the script that will tell
> me how the program ran on the remote host after it has finished running.
>
> What options do I have?
>
I'd suggest two things: (1) that you recheck the authentication
options under SSH - there is an option available for, ahh,
"machine authentication"; (2) check out vpn, which tunnels a
secure virtual network between 2 or more machines over an
insecure medium.

Of the two options, SSH is probably the easier, vpn the more
"elegant" solution.

HTH,

Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer

Will

2007-09-15, 7:16 pm

"Robert Melson" <melsonr@aragorn.rgmhome.net> wrote in message
news:13empmpm7eahm17@corp.supernews.com...
> I'd suggest two things: (1) that you recheck the authentication
> options under SSH - there is an option available for, ahh,
> "machine authentication"; (2) check out vpn, which tunnels a
> secure virtual network between 2 or more machines over an
> insecure medium.

But mechanically, how do I synchronously invoke a remote script on remote
Windows computer B running SSHD from a script running on computer A using
SSH?

I don't want to manually login to the remote computer. I need to automate
a process from a single script that runs on A and invokes some tasks on B.

--
Will

Michael Vilain

2007-09-15, 7:16 pm

In article <PeKdnR1-keUns3HbnZ2dnUVZ_umlnZ2d@giganews.com>,
"Will" <westes-usc@noemail.nospam> wrote:

> "Robert Melson" <melsonr@aragorn.rgmhome.net> wrote in message
> news:13empmpm7eahm17@corp.supernews.com...
>
> But mechanically, how do I synchronously invoke a remote script on remote
> Windows computer B running SSHD from a script running on computer A using
> SSH?
>
> I don't want to manually login to the remote computer. I need to automate
> a process from a single script that runs on A and invokes some tasks on B.

I used to do exactly what you describe from a central Solaris box to
other Solaris boxes using the supremely insecure rsh and rexec features
of Solaris. Since the NT boxes we had didn't have any form of rsh or
rexec (and we couldn't install such beasties), I was forced to use the
GUI on the console. I think the XP solution to this is Citrix or
PCanywhere?

I don't think the TCP/IP architecture of XP is setup the same way as
UNIX and initiating a "remote procedure call" encrypted or otherwise
isn't something that Windows can currently do as there's really no shell
(cmd.exe doesn't count).

Most likely, I'm massively wrong here. But again, I suggest that you're
most likely asking a group of people who know UNIX better than they
would know XP. Why not ask this in a Windows group or support forum?

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Robert Melson

2007-09-15, 7:16 pm

In article <PeKdnR1-keUns3HbnZ2dnUVZ_umlnZ2d@giganews.com>,
"Will" <westes-usc@noemail.nospam> writes:
> "Robert Melson" <melsonr@aragorn.rgmhome.net> wrote in message
> news:13empmpm7eahm17@corp.supernews.com...
>
> But mechanically, how do I synchronously invoke a remote script on remote
> Windows computer B running SSHD from a script running on computer A using
> SSH?
>
> I don't want to manually login to the remote computer. I need to automate
> a process from a single script that runs on A and invokes some tasks on B.
>
I can't give you an exact answer to your question because I
haven't done it myself, but it is possible to set SSH up to
do authentication without needing a manual login. For a
better answer than I can give, I'd suggest you post your
question to comp.security.ssh - the folks who hang out there
seem to know what they're talking about.

Once SSH is set up correctly, it's simply a matter of doing
something like "ssh foo.bar.com whatever_your_remote_command_is";
authentication proceeds automatically, remote command/script is
run securely, results returned securely to local machine, just
as in rsh/rexec. Since you want to completely automate this,
you'd probably want to put it under cron on the unix/linux
side, assuming the windows box is the remote on which you
want to run your command.

Sorry I can't be more helpful with how to set SSH up, but
believe me, it IS possible. The folks at comp.security.ssh
can probably answer your question without breaking a sweat.

VPN, as I indicated previously, is also a contender - once your
secure virtual network/connection is established, you can run
rsh or rexec just as you would over an unsecured connection.

Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"People unfit for freedom---who cannot do much with it---are
hungry for power." ---Eric Hoffer

Namegduf

2007-09-20, 1:30 pm

It involves setting it up to use keys to authenticate, rather than a password. Not sure of the details as I have never had to do this myself, either.

Robert Melson wrote:
> In article <PeKdnR1-keUns3HbnZ2dnUVZ_umlnZ2d@giganews.com>,
> "Will" <westes-usc@noemail.nospam> writes:
> I can't give you an exact answer to your question because I
> haven't done it myself, but it is possible to set SSH up to
> do authentication without needing a manual login. For a
> better answer than I can give, I'd suggest you post your
> question to comp.security.ssh - the folks who hang out there
> seem to know what they're talking about.
>
> Once SSH is set up correctly, it's simply a matter of doing
> something like "ssh foo.bar.com whatever_your_remote_command_is";
> authentication proceeds automatically, remote command/script is
> run securely, results returned securely to local machine, just
> as in rsh/rexec. Since you want to completely automate this,
> you'd probably want to put it under cron on the unix/linux
> side, assuming the windows box is the remote on which you
> want to run your command.
>
> Sorry I can't be more helpful with how to set SSH up, but
> believe me, it IS possible. The folks at comp.security.ssh
> can probably answer your question without breaking a sweat.
>
> VPN, as I indicated previously, is also a contender - once your
> secure virtual network/connection is established, you can run
> rsh or rexec just as you would over an unsecured connection.
>
> Bob Melson
>

Robert Melson

2007-09-20, 7:22 pm

Richard E. Silverman

2007-09-21, 1:28 am

>>>>> "RM" == Robert Melson <melsonr@aragorn.rgmhome.net> writes:

RM> In article <PeKdnR1-keUns3HbnZ2dnUVZ_umlnZ2d@giganews.com>, "Will"
RM> <westes-usc@noemail.nospam> writes:[vbcol=seagreen]
[vbcol=seagreen]

Just the other day I used the Tectia Windows SSH server to execute remote
commands on a Windows box, just via:

ssh windows-box "cmd /c foo.exe"

I'm not sure offhand about getting the return code; that is of course
implementation dependent. As for getting automated authentication, there
are ideas and discussion in the section of the snail book that Robert
pointed out, and here:

http://www.snailbook.com/faq/no-passphrase.auto.html

Probably, you'll need to use publickey authentication with a plaintext
private key on the client side. Note that if your Windows machine is part
of a domain, the account you log into will only have access to local
resources, since it won't have domain credentials. If you're coming
*from* a Windows box as well, some SSH implementations do support
GSS authentication which can pass Kerberos credentials across the
connection.

--
Richard Silverman
res@qoxp.net