Step 3: Permit remote users to access MVS resources (optional)

This step is necessary only if your installation allows users to issue remote execution commands without the requirement of specifying a password on the remote execution client.

Use the following steps to ensure that the server can correctly access necessary MVS™ resources. You can use z/OS® Security Server (RACF®) or an equivalent security program.

1. Verify that your system has been configured for allowing surrogate job submission as described in z/OS Security Server RACF Security Administrator's Guide (SC28-1915) or by using an equivalent security program.
2. Authorize the TSO Remote Execution server to submit jobs for the MVS user ID specified with the -l option of the RSH command. This can be done with the RACF facility as described in z/OS Security Server RACF Security Administrator's Guide (SC28-1915), or by using an equivalent security program.
3. Define an mvs_userid.RHOSTS.DATA data set and authorize the TSO Remote Execution server user ID permission to read this data set. This can be done with the RACF facility as described in z/OS Security Server RACF Security Administrator's Guide (SC28-1915), or by using an equivalent security program.
   Note: This is the user ID used to start the RXSERVE address space.

   This data set identifies the Remote Execution clients that can execute MVS commands remotely by sending an RSH command.

   When a Remote Execution client sends an RSH request to the TSO Remote Execution server, the request includes the local user ID of the client user (local_userid) and, if the client user specified the -l option of the RSH command, the request also contains the user ID to use on the remote host (mvs_userid). If the client does not specify the -l option, the user ID to be used on the remote host is assumed to be the same as the local_userid.

   When the TSO Remote Execution server receives an RSH command without a password, the server looks for a data set called mvs_userid.RHOSTS.DATA. The mvs_userid.RHOST.DATA data set contains one or more entries. Each entry consists of two parts, a fully qualified name of the client user's host and a local_userid associated with that host. The local_userid is case sensitive. If the data set exists, the server reads it and looks for an entry with a host name that matches the client user's host. If the user ID specified on this entry in the RHOSTS.DATA data set matches the local_userid passed on the RSH command, the RSH command continues processing. If the entry does not exist, the server responds to the client with message EZA4386E Permission denied.

   Tip: If the client connected to this host through a link-local address, the client's host name generated by the resolver can be in the format hostname%scope. Adding %scope information to the appropriate RHOSTS.DATA client host definitions results in a more efficient search for a matching client host name. For details on the support for including scope information on configured host names, see z/OS Communications Server: IPv6 Network and Application Design Guide.

   In the following example of an RHOSTS.DATA data set, the MVS client user mvsuser is allowed to issue the RSH command without a password from host rs60007 with a local AIX® user ID of aixuser.

   Example of mvsuser.RHOSTS.DATA data set:

   rs60007.itso.ral.ibm.com aixuser

4. Users may be authenticated using Kerberos or GSS. If the username in the Kerberos or GSS credentials matches the local user ID (local_userid) of the client supplied by the RSH client, then no password is required.