The daemons rshd(1)
and
rexecd(1)
can allow access with very little authentication (passwords are not
checked) by looking at a file called .rhosts(5)
in a user’s home directory. Since this feature presents a security
threat, it is often disabled. The Interix daemons will read this
file only if it is protected in the following manner:
For information on using Windows security to protect files, see Windows Help.
Windows Services for UNIX provides two remote shell servers: the Windows-based Remote Shell service and the Interix rshd(1). If the Windows Remote Shell service is installed, it is enabled by default and the Interix rshd daemon is disabled by default in /etc/inetd.conf. The Windows and Interix versions of these servers should not be run at the same time because they will both try to access the same TCP/IP port, causing unpredictable results. To avoid problems, you should ensure that only the Windows or the Interix version of these servers is enabled at a time.
After an Interix daemon validates the remote user in the
.rhosts file, it still cannot create the user's context
without a password. To allow the traditional UNIX behavior on
Interix, you must use the regpwd(1)
command to store your password in a secure location accessibly only
to privileged processes.
Normally, Interix daemons are automatically started by the inetd daemon. This daemon, in turn, is normally started by /usr/sbin/init, which is run when the Interix subsystem starts, and it is run logged on with the local Administrator account. Because the Administrator account is a local account, any process, including an Interix daemon, logged on with that account does not have access to network resources. As a result, if the user's home directory is not on the local computer (that is, on a network share on a remote computer), then the Interix daemon cannot access the .rhost file and the automatic login process will fail. To work around this problem, a domain administrator must create a domain account that provides access to network resources so the user's home directories can be accessed. For more information, see Creating a user for inetd. If it is necessary to use this method, inetd must be installed and run as a Windows service, not as a daemon using /usr/sbin/init.