rshd - Remote Shell Daemon for Windows NT/95 version 1.0

Written by Silviu C. Marghescu (http://www.cs.umd.edu/~silviu)
Copyright (C) 1996  Silviu C. Marghescu, Cornerstone Technologies, Inc.
All Rights Reserved.

rshd is free software; you can redistribute it in its entirety 
in any form you like.  If you find any bugs, feel free to send me an 
email at silviu@c-stone.com.  If you have added new features to rshd, 
please send me all the source code modifications, including the version 
of rshd that you are based on.  Your additions may benefit other users.


Disclaimer
==========

rshd is distributed hoping that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Good data processing procedure dictates that any program be
thoroughly tested with non-critical data before relying on it.
The user must assume the entire risk of using the program.
THE AUTHOR SHALL NOT BE HELD LIABLE FOR ANY 
KIND OF DAMAGES OR CLAIMS THAT DIRECTLY OR INDIRECTLY RESULT FROM 
USING THIS SOFTWARE.


Description
===========

rshd is a multithreaded daemon process that listens for connections on port
514 (tcp port for rsh protocol), runs commands passed by clients and sends
back the results.  It was my experience that the rshd service included in the
Windows NT Resource Kit does not follow the BSD specification for the rsh protocol;
it works fine with the rsh client in NT, but other clients fail to connect.
This implementation of rshd tries to get as close as possible to the BSD specs
(http://www.bsdi.com).

Important note: rshd was designed and implemented to be convenient and reliable,
rather than tightly secure.  A client trying to connect to rshd will have to pass 
a security clearance process, but rshd is probably far from a secure service.
If security is of major concern across your network, you should be very careful
when using this service.  My target for rshd was a closed network, or a network
guarded by a firewall.


Requirements
============

o An Intel processor based machine running Microsoft Windows NT or 95.
o Window Socket DLL installed properly (version 1.1 or higher).


Installation
============

This package contains the following files:
	readme.txt - this file
	rshd.exe - the rshd daemon executable
The source distribution also contains:
	rshd.cpp - the C++ source file (actually mostly C, but I prefer to define
		variables when I really need them; plus, I like the // comments)
	rshd.ide - the project file for Borland C++ 5.0 users
	rshd.mak - the project file for Microsoft Visual C++ 2.0


Running rshd
============

In its current version, rshd is not a Windows NT service.  It has been tested with
the srvany.exe utility in the Resource Kit and it seems to work just fine.
Should you decide to run it as a service using srvany.exe, during debugging
make sure you allow the service to interact with the desktop in order to be
able to read all the messages.

Command line options:
-d	enables debugging messages. Good for those days when nothing works...
-1	no stdout redirection. By default, rshd will redirect the output of your
	command into a temporary file and send the result back thru the client
	socket.  If however you are not interested in the output, or the command
	is already redirected, this option will prevent stdout redirection.
	Note that the option is global, meaning it will disable redirection 
	regardless of the commands you're passing...
-2	no stderr redirection.  Same as '-1', but for stderr.  At this point it
	should be noted that under the BSD rshd specification, the client can pass
	an auxillary tcp port number that the daemon can use to send the stderr
	output back.  The rshd will connect to that port if provided and send
	back the stderr, unless this option is given.  If no alternative stderr port
	is provided, rshd will use the main socket for both stdout and stderr.
-4  4DOS command shell.  Different shells and different operating systems have
    different ways of redirecting output, especially for the standard error.
    rshd was tested in the following configurations: CMD.EXE and 4NT.EXE on 
    Windows NT; COMMAND.COM and 4DOS.COM on Windows 95.  If you're running 4DOS
    on Windows 95, make sure you set the '-4' command parameter, otherwise the
    stderr redirection will fail.
-v	displays the rshd version.
-s	stronger security enabled.  By default, when the client credentials can't
	be checked, rshd assumes it to be friendly and runs the command.  If that
	creates security concernes, this option will accept the connection to a client
	only if everything checks out.
-r	no .rhosts checking.  Per BSD rshd specification, rshd loads the 
	<windir>\system32\drivers\etc\.rhosts file and builds a list of trusted
	hosts.  Any further connections will be accepted only from a host in the
	list.  '-r' disables this checking.  Note that this is a major security
	issue: if your network is not closed or guarded by a firewall, anybody
	can connect thru the rsh protocol and run commands on your machines.
	Use this option only if you know exactly who is running what across your
	network!

Stopping rshd by killing it will almost always work, but it is the worst way of
doing it.  To gracefully stop it, use an rsh client and send the "rshShutdown"
command; rshd will know what to do then...

I have tested rshd with the following rsh clients: WinRSH (both 16 and 32 bit
versions; this was the client I needed to use and didn't work with the Resource
Kit implementation of rshd); NT client of rsh; SunOS client of rsh.  The main
difference between WinRSH and the other rsh clients is that WinRSH does not open
a stderr additional port; rshd will send both the stdout and stderr output thru
the main socket.


Rebuilding rshd
===============

You probably have the sources already...  I've built rshd with both Visual C++
and Borland C++; the .ide file is the Borland project and the .mak is the one
you need for Visual C++.  Make sure you define the appropriate macro (first lines
in rshd.cpp define either VISUALCPP or BORLANDCPP).


Known problems
==============

There seems to be a problem with the stderr connection some of the rsh clients are
requesting.  First connection works always fine, but the second one fails if it
comes within a minute or so.  That is due to the fact that somehow, the stderr socket
is not properly closed and it just sits there for a while until it times out.  I am
currently trying to fix this.  WinRSH always worked for me, on every platform I've 
tried it...
 

Whether you have good or bad comments, improvements and suggestions, I would like
to hear from you at silviu@c-stone.com.
