yet another remote-execution daemon for Windows
It seems to be quite common in large-company environments for employees to be given a Windows machine on their desktop, and for there to be Unix server machines elsewhere in the building that they can connect to (either using Telnet or SSH, or a Windows X server such as Exceed). Quite often there is also a dual-protocol file server that allows the Windows machines and the Unix machines to share at least some of their file systems.
If you're predominantly a Unix user and you find yourself in this
sort of environment, it can be quite inconvenient. Picture the
scene: at your Unix shell prompt, you've just tab-completed your way
down a ten-level path name in one of these shared file systems, in
search of a file that someone told you you needed to read. When you
find it, it turns out to be a
.DOC Word document.
Clearly the last thing you want to do at this point is to
bring up a local Windows Explorer, and click your way right down the
same ten-level directory path to get back to the same file. What you
really want is a little utility, perhaps called
wf (for "Windows File"), which would automatically
translate the pathname from Unix syntax into Windows, automatically
contact your Windows machine, and ask it to launch the file with
whatever viewer program seemed appropriate.
This is the main problem that DoIt solves. It has a few other handy features too, but the above is mainly what it's for.
Here is the complete list of features that DoIt provides, so that you can tell whether it will be useful to you before downloading.
wf myfile.doc". DoIt will automatically turn this into a fully-qualified Unix path name, then feed it through a set of user-defined path name translations, and end up with a Windows path name that accesses the same file.
DoIt is distributed under the MIT licence, so it is free to copy, redistribute, use and reuse. For more details, see the file called LICENCE in the distribution archive.
DoIt comes with NO WARRANTY. To the best of my knowledge it works correctly and provides the level of security it tries to provide, but I might be wrong. If you are in doubt, you should perform your own security review of the code.
DoIt comes in two parts: a client and a server.
The server is a Windows user-level process. You run it in your Windows session (perhaps in your Startup group so that it appears as soon as you log in), and it sits in your System Tray and listens for connections on TCP port 17481. The DoIt server does not run as a Windows NT Service, so you do not need to be the administrator to install it. Each user of a multi-user NT machine can install and configure DoIt independently.
The client is a simple Unix program which performs all the necessary path translations and then sends commands to the server. Pathname translations must be entered manually into a configuration file on the client Unix machine(s).
The protocol spoken between the client and the server is cryptographically protected to provide confidentiality, integrity and two-way authentication. In other words, eavesdroppers cannot tell what commands you're sending to your Unix box or what the responses are; active man-in-the-middle attackers cannot modify the command you send or the response you receive without you noticing; nobody can pretend to be your server in order to intercept the commands you send; and crackers elsewhere on the network cannot send their own commands to your Windows machine and convince it they're genuine.
Unlike SSH or similar protocols, however, DoIt does not use a key exchange phase. It relies on the client and the server already having access to a shared secret key. You need to have set this key up by some other means. (This decision is largely taken on grounds of performance; some of DoIt's functions need to be performed very promptly, and a second or two of cryptographic key exchange would seriously impact this.)
If you have a shared file system between your Windows and Unix machines, one obvious solution is to create your shared secret file and store it on this file system. Since most network file system protocols are not cryptographically protected, this will now be the weak link of the system in terms of security: an attacker able to eavesdrop on network packets will now be able to learn your shared secret and then instruct DoIt to run any command they like on your Windows machine. However, if this is the case then your unencrypted network file system is likely to have been the weak link in your internal security in any case, so DoIt will most likely not have made matters any worse. I use this method myself and I don't think it's a problem (but then, my company's network is fully switched, so eavesdroppers will have a reasonably hard time anyway).
At some point it might be worth adding a standard mechanism for key exchange which can be run every few hours independently of the data connections. This would require some design work, and there would also need to be public keys for the clients and servers. And for this security enhancement to be worthwhile, you would suddenly have to be careful not to store anything on the unencrypted shared file system!
LEGAL WARNING: Since DoIt uses strong encryption, it may be illegal to download and use it in some jurisdictions. You may find this site useful (it's a survey of cryptography laws in many countries) but I can't vouch for its correctness. If there is interest, I might consider providing a version of DoIt that uses cryptography only for authentication and integrity protection, and does not encrypt data against eavesdroppers.
The archive below contains all the DoIt source code, and a
pre-compiled Windows server executable. You will need to build the
Unix client program yourself (because it will be different on every
different Unix system). For this you will need a Unix C compiler.
Most Unix systems come with one of these, and it is probably
possible to install
gcc on any that do not.
The DoIt archive is available as a ZIP file and as a Unix
BE AWARE that currently the DoIt wire protocol is not finalised. If you attempt to use one version of the DoIt server with a non-matching version of the client, I cannot guarantee whether things will work fully, partially, or not at all, and I also cannot guarantee that either client or server will give sensible error messages explaining the problem. DoIt is not very mature software yet, and I don't want to tie myself down to supporting a broken protocol design for the next few years. Always use matching client and server versions.
Please report bugs to firstname.lastname@example.org. Be sure to include all the version numbers of the DoIt files in your bug report (these are provided in the file called README in the archive).
You might find it helpful to read this article before reporting a bug.
Patches are welcome, especially including improvements to the documentation.
PC has written a Belorussian translation of this page.