Remote Shell Services in SFU

  • Article

By Charlie Russel, Microsoft MVP for Windows Server Interoperability

Abstract

Microsoft® Windows® Services for UNIX 3.5 provides two separate mechanisms for supporting remote shell capabilities between systems—the Windows Remote Shell Service and the Interix Remote Shell Daemon (rshd
). This white paper covers the configuration of both mechanisms and identifies some common configuration problems and their resolutions.

*

On This Page

Introduction Introduction
Installation Installation
Windows Remote Shell Service Windows Remote Shell Service
The Interix Remote Shell Daemon The Interix Remote Shell Daemon
Conclusion Conclusion

Introduction

Microsoft® Windows® Services for UNIX 3.5 (SFU 3.5) includes key interoperability components that let Microsoft Windows computers provide remote shell services (rsh) to both Windows and UNIX computers. To enable these components to work effectively, SFU 3.5 must be correctly set up to allow access to the remote computer.

SFU 3.5 includes two separate and distinct remote shell servers—a Windows-based rshsvc.exe
that runs as a native Windows Service and uses the Windows cmd.exe
as the shell and an Interix rshd
that can be enabled via inetd.conf
that uses the user’s default Interix shell.

Additionally, SFU 3.5 provides support for other r-utilities, including rdist
,rcp
, and rlogin
when the Interix version of Remote Shell Services is used.

Note: This document throughout refers to resources and authentication of UNIX users and computers. The reference is shorthand for “UNIX and Linux” users and computers. 

Warning: rsh and the r-utilities in general are inherently insecure and should be installed and enabled only on systems that are not directly exposed to untrusted networks.

Installation

SFU 3.5 uses the Microsoft Installer and follows the same familiar conventions as the rest of the Microsoft installation programs. The purpose of this section is not to provide help for using the Microsoft Installer because that information is available from other sources. These include Knowledge Base articles about installing specific portions of Services for UNIX from the command line and the install.htm file on the distribution media for SFU 3.5. The Knowledge Base article HOW TO: Install Windows Services for UNIX 3.0 on Windows 2000 (KB#: 321712), while originally written for SFU 3.0 and Microsoft® Windows 2000, provides a useful and accurate description of the installation process for SFU 3.5 and is applicable to all versions of Windows that SFU 3.5 supports.

What Needs to Be Installed?

What needs to be installed depends on which rsh you wish to use. Although both can be installed, only one of them can be enabled and running. In addition, the configuration requirements are slightly different, so it pays to make a decision early and stick with it.

Windows Remote Shell Service

The Windows Remote Shell Service (rshsvc.exe) is automatically installed on Windows Server-level products when you perform a standard installation and is automatically pre-selected for a custom installation on these products. On workstation-class products (Microsoft® Windows 2000 Professional and Windows® XP Professional, Tablet PC Edition, and Media Center Edition), the default installation will not install the Windows Remote Shell Service—you will need to do a custom install and select it.

Rshsvc.exe resides in the %SFUDIR%\common directory. It can also be installed by running “rshsvc.exe –install” from the command line.

If you have a User Name Mapping server on the network, you can use it to map UNIX users to Windows users. User Name Mapping is installed only by default on Domain Controllers but can be selected as part of a custom installation on all classes of supported Windows operating systems. For more information about User Name Mapping, see the NFS Authentication white paper on Microsoft TechNet.  

Note: For clarification, when I am referring to the Windows Remote Shell Service (rshsvc.exe) as opposed to the Interix remote shell service daemon (rshd
) throughout this paper, I will use “WinRSH” for the Windows Remote Shell Service.

Interix rshd and r-utilities

The Interix subsystem and base utilities are automatically installed as part of the default SFU 3.5 installation on all machines. The installation includes the rsh, rstart and rdist client and server utilities, and the rcp and rlogin utilities. They are disabled for security reasons and must be explicitly enabled.

Windows Remote Shell Service

WinRSH runs as a Windows Service. When started with the –m
option, WinRSH will take advantage of the specified User Name Mapping Server. WinRSH uses a .rhosts
file to control access to the local machine, which acts as an rsh server. The .rhosts
file contains a list of remote machines and their users that are permitted to access the local machine. The shell provided to the remote user is the command line shell cmd.exe
.

Configuration

WinRSH is normally installed to run under the local System account and is started with no additional parameters. When installed automatically on Microsoft® Windows 2000 Server™ or Microsoft® Windows Server™ 2003, it is set initially to “Disabled” status and will not run.

Warning: When installed as part of a custom installation, WinRSH is set to automatically start on boot. This is a significant security concern, so you should disable the service if you aren’t actively using it and should understand the security implications of enabling the service before you actually enable it.

To Enable Automatic Startup

Open the Services console, either separately, or as part of the Computer Management console, as shown in Figure 1.

Figure 1. Computer Management console

Figure 1. Computer Management console

Double-click the Remote Shell Service to open its properties page, as Figure 2 shows.

Select the startup type as Automatic to have WinRSH start automatically with Windows. Then add any Start Parameters required. (See the Command Line section for WinRSH for details about the available parameters.)

Figure 2. Remote Shell Services Properties dialog box

Figure 2. Remote Shell Services Properties dialog box

Domain vs. Local Accounts

WinRSH does not support domain accounts and authentication, and it does not distinguish between local user jdoe and domain users EXAMPLE\jdoe and DOMAIN\jdoe. If user EXAMPLE\jdoe is logged in and runs the rshpswd utility to register a password, it will be stored correctly, but then logins via WinRSH from any one of the three accounts will succeed and each will have the credentials of the local user jdoe.

User Name Mapping

When started with a –m <servername>
option, WinRSH will use the User Name Mapping server at <servername>
. The authentication process flow is:

  1. Is the local user name identical to the remote user name?

  2. Is the remote user enabled via the .rhosts
    file?

  3. Is the local user name a valid Windows user account?

    If not, does the User Name Mapping server at <servername>
    provide a map to a valid Windows user account?

If the process fails at any step, it immediately stops and rejects the client request. If rshsvc.exe is started without the –m <servername>
parameter, then no check against a User Name Mapping server is performed.

.rhosts

WinRSH uses a .rhosts
file to control which machines and users are allowed to open a shell remotely. The .rhosts
file resides in the location specified by the registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RshSvc\RhostsPath

The default location is %windir%\system32\drivers\etc. To simplify support, you should change this location only for a compelling reason.

The format of the .rhosts
file is:

machine1 user1 user3 # user1 and user3 can log in from machine1
+ user2        # user2 can log in from any machine
machine3 user1
machine4 +     # All users on machine4 can log in
+ +            # All users from all machines!

The WinRSH .rhosts
file is not the same as a typical UNIX .rhosts
file and is actually closer to the /etc/hosts.equiv
file. It does not support entries without a specified user—lines with only a machine name will be ignored. Each user who needs to access a machine from a remote machine needs to have an entry in the .rhosts
file.

WinRSH does not support the traditional use of the –l <user>
syntax from remote clients to shift the login user. Such requests will be rejected with an “Access denied” message returned to the client.

The Rshpswd Utility

In a traditional UNIX system running the remote shell daemon, users identified in the .rhosts
file do not need to enter a password when running an application on a remote system. This is not possible on a Windows system, so the rshpswd
utility is used to store the currently logged-in user’s password in the Local Security Authority (LSA).

Caution: An inherent limitation of WinRSH is that user EXAMPLE\Joe and DOMAIN\Joe are treated as the same user, creating a security hole when used with the rshpswd utility to store the user’s password for use by rsh.

The rshpswd
utility must be run on the target remote computer before the utility can be used by the calling rsh
client. Rshpswd
is run from the command prompt when logged in as the user whose credentials will be used by the rsh
client. It accepts no parameters but rather prompts simply for the current user’s password and then stores it for WinRSH to use.

Command Line

All three programs that WinRSH uses are run from the command line and have no graphical user interface.

Rshsvc

The service itself, rshsvc, accepts the following arguments:

  • -install—Installs the service into the list of Windows Services

  • -remove—Removes the service from the list of Windows Services

  • -start—Starts WinRSH

  • -stop—Stops WinRSH

  • -m <servername>—Specifies the User Name Mapping server to use

  • -p—Does not use passwords stored locally for users

The full syntax of the rshsvc command is:

rshsvc (-start [-m MappingServer] [-p] | -stop | -install [-m MappingServer]| -remove)

Rsh

The client, rsh, runs as a Windows command line program and accepts the following options:

  • host—The host name or IP address of the remote computer

  • -l username—The username to run as on the remote computer (not supported by WinRSH but useful for connecting to remote UNIX computers)

  • -n—Redirect the input of rsh to NULL

  • **command—**The command to run on the remote computer

The full syntax of the rsh command is:

RSH host [-l username] [-n] command

Rshpswd

The password registration utility for WinRSH does not accept any command line parameters. It simply prompts for the current user’s password.

Troubleshooting

Troubleshooting WinRSH can be trying. The single biggest help, however, is the log file created in the directory where .rhosts
resides. The log filename is rshhistory
, and it records both successful and unsuccessful connections. Additional events are stored in the Windows Event Viewer.

Another important cause of failure is .rhosts
permissions. This failure will cause an “Access denied” message to the client and will be logged in the Event Viewer.

Character Mode Only

Applications that need to be run remotely must be character mode only and cannot require user input. The remote shell does not have access to graphical resources, and it does not have a facility for interactive user input. WinRSH is appropriate for running scripts remotely—but not for any application that requires interactive user input. If you need to run graphical applications on a Windows computer remotely, use Remote Desktop.

Mounted Resources

Each rsh session has access only to mounted network drives that are explicitly mounted as part of that session. If an application or script needs access to a network resource, even one that is already mapped at the console of the Windows machine, the script will need to map the drive as part of the current session. So, for example, if a script or application requires that drive “z:” be mapped to \\examplesrv\share, then the script would need to map the drive first with a net use
command. Alternatively, if the script supports the Universal Naming Convention (UNC), the resource can be used without explicit drive mappings.

Service Fails to Start

While there can be many reasons why a service fails to start, the most common problem with WinRSH is that both the Windows service and the Interix rshd
are enabled. Only one is allowed to run at a time. From an Interix shell, edit the file /etc/inetd.conf and ensure that the line controlling the remote shell service is commented out.

# shell stream tcp  nowait  NULL  /usr/sbin/in.rshd       in.rshd –a

Stop and restart the inet daemon, or issue a kill -1 to the process.

See Enabling rshd
  below for details about editing inetd.conf.

“Invalid User or Password” Error
“Unable to Execute Command” Error

This error occurs when a user has not stored the correct password on the computer running Remote Shell service.

Solution The user should interactively log in to the server and then run the rshpswd utility to store the user’s local password. The user should attempt to run rsh commands from the remote computer to verify that the password has been stored correctly.

“Access is Denied” Error

A user receives this error when the user does not have access to run rsh commands on the server. The most common cause is that the .rhosts
file in %WINDIR%\system32\drivers\etc does not have an entry for the client computer and the user.

Solution: Update the .rhosts
file to give access to this to the user and the user’s host computer.

Recap—Steps Required for Windows Remote Shell Service

Provided below is a quick recap of the steps required to provide rsh connectivity with the Windows Remote Shell Service.

  1. Install the service from the SFU 3.5 installation medium onto the target system.

  2. Enable the service to start automatically or manually, as appropriate on your system.

  3. Create a .rhosts
    file in the %windir%\system32\drivers\etc directory of the target system. The file must contain a list of machines and users who will be allowed to connect to the target system and should be readable by members of the local Users group—but not writable. The normal inherited permissions in the default directory should be appropriate.

  4. Log in to the target system as the user who will connect to the system.

  5. Run rshpswd
    to store the user’s password.

  6. Connect from the originating system by using a simple command such as “set” to test connectivity. For example, to connect to system example-srv as user Jane, the command might read:

    rsh example-srv set

The Interix Remote Shell Daemon

The Interix Remote Shell Daemon, rshd
, runs as a daemon initiated by the inetd
process and behaves in a more traditional UNIX manner. By default, rshd
is disabled.

Enabling rshd

To enable the Interix Remote Shell Daemon, edit the file /etc/inetd.conf
by using the Interix vi
or other Interix or UNIX editor. Do not use Windows Notepad
or other Windows editor, as they will insert Windows end-of-line characters into the file. Find the line that reads:

#shell   stream   tcp   nowait   NULL  /usr/sbin/in.rshd in.rshd –a

Remove the “#” from the beginning of the line and save the file.

The exact sequence for editing the file in vi
, if you are not comfortable with vi
yet, is:

vi /etc/inetd.conf
/#shell<return>
x
:wq<return>

Once the inetd.conf file is edited, double-check that WinRSH is not running. If necessary, stop the service and set its status to manual or disabled.

In order to start rshd, you must force inetd
to re-read its configuration file. The simplest way is to use “kill -1” on the inetd
process. The manual steps to do this are:

ps –ef | grep inetd
kill -1 <PID from the previous command>

Or, as a one-liner on most systems:

kill -1 $(ps –ef | grep /usr/sbin/inetd | grep –v grep | cut –c 14-17)

Or, if you prefer:

kill -1 $(ps –ef | grep /usr/sbin/inetd | grep –v grep | awk '{print $2}' )

If you stop and then restart the inetd process, make sure you restart it as the local “Administrator” user. Restarting it from another account will cause rshd
to fail to authenticate connections.

hosts.equiv and .rhosts

The Interix rshd
uses a more traditional authentication mechanism, with both hosts.equiv
and .rhosts
supported. If you choose to use hosts.equiv
, you can specify which users have permission to log in to the local machine from that remote machine, but they can log in to any non-privileged account on the local machine. If you specify a machine name only, then all users from that machine can connect to any non-privileged account on the local machine. The format of hosts.equiv
is “machine user” as in this example:

unixhost1
unixhost2 charlie
unixhost2 wally
example-xp

Notice that there are two different users from unixhost2 who are permitted to connect to our target machine. Each user appears on a different line, as the example shows. Unfortunately, the Interix rshd
does not support the more sophisticated formats for .rhosts
and hosts.equiv
that other UNIX systems support.

The Interix rshd
also supports a user specific .rhosts
file. This file, which is checked only if a hosts.equiv
match is not found, follows the same format as hosts.equiv
but only allows connections to the specific user account.

As in traditional UNIX systems, the .rhosts
file must reside in the user’s home directory, must be owned by the user, must be a regular file, and must be writable only by the user. Also, you should use only the Interix vi
utility or other UNIX editor to create and edit the file. Windows editors can insert Windows text format line endings or other stray characters that will cause a failure.

When the target account is a member of the local Administrators group, /etc/hosts.equiv
is ignored and only the .rhosts
in the target user’s home directory is checked.

regpwd

The regpwd utility is used to store the user password in the LSA in much the same way that the Windows rshpswd utility is used to store the user password for WinRSH. However, with rshd
, if the target user account has not stored the user password by using the reqpwd utility, the remote user can still theoretically connect to the target user account—but with reduced credentials. Because the connection will not allow access to network resources, in an environment in which the users’ home directories are on a networked share, it will have the effect of disabling access to their home directory and the session will default to the root directory(“/”).

Rcp

The UNIX remote copy, rcp
, is supported by the Interix rshd
. If rsh
works correctly, then rcp
will also work. See the man
pages for rcp
for full syntax.

Enabling rlogin

Interix also supports remote logins using the rlogin client and rlogind
daemon. Remote logins do not require that a password be stored on the target system—the remote user is simply prompted for a password. However, passwords are then passed in clear text over the network. On a traditional UNIX system, if all the necessary conditions are met, remote logins via rlogin do not require a password if .rhosts
or hosts.equiv
allows the remote user. Under Interix, if the default permissions and ownerships have not been changed and the SYSTEM account runs the Interix subsystem, then the behavior is as expected except that regpwd must be used to store the password just as with rshd
. In both traditional UNIX and Interix systems, if the remote login cannot occur automatically, the remote user is prompted for the target user’s password, and if correctly provided, is logged in.

Command Line

The rsh
, rshd
, rcp
, and rlogin
utilities are pure command line utilities. You can find full details of the available options for each utility by using the Interix man
pages. For example, man
rshd
yields, in part:

rshd(1)                                                       rshd(1)

  rshd

  NAME

    rshd - remote shell server

  SYNOPSIS

    rshd [-alnL]

  DESCRIPTION

    The rshd(1) server is the server for the rcmd(3) routine and,
    consequently, for the rsh(1) program. The server provides remote
    execution facilities with authentication based on privileged port
    numbers from trusted hosts.

    The following options are supported by rshd(1):

    -a
        Ask host name for verification.

    -l
        Prevent any authentication based on the user's .rhosts file.

    -n
        Disable keep-alive messages.

    -L
        Log successful accesses very verbosely.

Troubleshooting

Unfortunately, the Interix rshd
daemon does not provide a readily available log of all failures and successes, as does WinRSH. However, when started with the –L option, it will write quite verbose success messages to the syslog. By default, syslogd
is not enabled in SFU 3.5, so you will need to first enable it. See the man
pages for syslogd
for all the details.

The most common failure points for the Interix rshd
are:

  • Trying to enable rshd
    without first disabling and stopping the Windows Remote Shell Service.

  • Not having properly configured .rhosts
    and hosts.equiv
    files, especially the .rhosts
    file, which should have permissions that do not permit anyone except the user, who must also be the file owner, to write to the file.

  • Incorrect permissions in the .rhosts
    file. This file must not be writable by any account except the user.

  • Using h hosts.equiv
    to grant permission too broadly when access is needed to a privileged account.

  • DNS failures between the client and server systems that cause the machine names in .rhosts
    or hosts.equiv
    to not be resolved correctly. A good practice is to use IP addresses during initial testing and setup. Once everything is working as expected, it’s best to change back to using DNS resolvable names to avoid later configuration issues if IP addresses change.

Specific Failure Messages at the Client

In the event of failure, especially if syslogd
has not been enabled, you still have some help about where to look for problems, based on the exact error message returned to the client. Specifically:

  • Access is denied—Usually indicates that the Windows Remote Shell Service is running and that you have not configured it to allow this remote user and machine access.

  • Connection refused—Either inetd
    is not running, or it has not been configured to enable rshd
    and rlogind
    . Can also manifest itself as the client just “hanging,” apparently waiting for something to happen.

  • Permission denied—This can be many things. Some specifics to check include:

    • The inetd
      process (/usr/sbin/inetd
      ) must be owned by the local administrator account. If you have stopped and started inetd
      manually with another account, this will cause the error.  

    • Verify that /etc/inetd.conf
      is configured to start rshd
      and rlogind
      . Force a re-read of the configuration file by stopping and starting the inetd
      process from the local administrator account or issuing a kill -1 to the process as described under Enabling rshd
      .

    • Verify the entries in the /etc/hosts.equiv
      and ~/.rhosts
      files.

    • If the client is requesting connection to an account that is a member of the local Administrators group, /etc/hosts.equiv
      is ignored and a valid ~/.rhosts
      must be present.

    • Enable syslogd
      and try again, checking the messages in /var/adm/log/messages
      .

Conclusion

Microsoft Windows Services for UNIX provides both a Windows-based and Interix-based remote shell capability. Because both cannot be used at the same time and their configurations and capabilities are somewhat different, the systems administrator should make a decision about which services to use and then configure and enable only that set of services. Although the remote shell capability is inherently an insecure protocol, it can provide a useful facility between trusted systems that are not exposed to untrusted networks. If a similar capability is required that has greater security, the Secure Shell (ssh) is an appropriate option and is available for both Windows and for the Interix subsystem.