The HOME.rhosts File Using UNIX r−Commands — An Example

The etchosts.equiv file defines the hosts and users that are granted r command access to the system. But this file can also define hosts and users that are explicitly denied trusted access. Not having the trusted access does not mean that a user does not have access to the system at all, it just means that the user is required to supply a password. The basic format of entries in the etchosts.equiv file is: [+ | −][hostname][username] where hostname The name of the trusted host, optionally preceded by a plus + sign; a + sign used alone means any host. If a hostname is preceded by a minus − sign, it explicitly means that the host is not an equivalent trusted system, and all users from this host must always supply a password. username The name of the super−trusted user on the trusted host who is granted access to all user accounts without being required to provide a password the root account is not included. If a username is preceded by a minus − sign, it means that the user is not trusted regardless of what may be true about the host, and must always supply a password. Some of the specified entries are not recommended For example, the standalone + sign in place of a host name, which allows access from any host anywhere, is strongly discouraged. Also, the entry + somename will open your system to the user somename from any host worldwide, with full rights over all user accounts. An intruder who can create the account somename on any host can gain complete control over all user accounts on your system. Generally the leading + sign for hostname should be avoided, because a simple typographical error could give a standalone plus sign an extraneous space between + and hostname will have this effect. Also, the etchosts.equiv file should not begin with the − sign as the first character, because it confuses some systems, though it is legal. The selection of trusted hosts is up to the system administrator, but considerable attention should be paid to this issue.

19.2.2 The HOME.rhosts File

The .rhosts file grants or denies password−free r command access to a specific users account. It is placed in the users home directory and contains entries that define the trusted hosts and users in exactly the same way as etchosts.equiv file, but only for a single user account. This file can be useful to establish equivalence among the different account names that a user can have on different systems. It is not always possible for a user to open accounts under the same login name everywhere. This file enables users to skip this obstacle. By putting all hostname−username pairs in the users .rhosts file, the user can use commands from those hosts without being queried for a password despite the differences of the usernames on those hosts. However, the .rhosts file cannot override the hosts.equiv file. The two files are processed in the following way: the hosts.equiv file is searched first, followed by the users .rhosts file, if it exists. The first explicit match determines whether or not password−free access is allowed. If the hosts.equiv file does not exist, however, then the .rhosts file alone determines password−free access to the 444 When a root user attempts to access a system via r commands, the hosts.equiv file is skipped, and only the .rhosts file is consulted supposing as a superusers home directory. This allows root access to be more tightly controlled and separated from other users who can then be configured collectively by the hosts.equiv file.

19.2.3 Using UNIX r−Commands — An Example

To better understand the advantages of using UNIX r commands in a network environment, let us suppose the following arbitrary, but realistic, situation. Our task is to check the status of a number of processes running on a number of hosts and to generate a corresponding report. Let us suppose a list of hosts is given in the file usrlocalindexHostList each line includes a single hostname; a list of processes in the file usrlocalindexProcessList each line includes a process name; and the report is written in the file usrlocallogsReport. Upon successful completion, the report should be printed or e−mailed. The ksh script named check_processes, owned by the user chk_oper, and executed from the host CentralHost is supposed to do this job efficiently. The script remotely checks the status of the listed processes on each of the listed hosts this could be hundreds of hosts, and hundreds of processes, and locally displays the related status messages and writes them into the Report file. The only requirement for successful script execution is to provide the equivalency between CentralHost and all checked hosts for the user chk_oper, who executes the script this can be done through the etchosts.equiv file or the .rhost file in the home directory for the user chk_oper. The script is presented below: cat usrlocalbincheck_processes binksh This is the script check_processes Purpose: To check the status of listed processes at listed hosts Input: Listed processes in the file usrlocalindexProcessList; Listed hosts in the file usrlocalindexHostList. Output: generated report at standard output and in the file usrlocallogsReport. could be printed on default printer andor email to the user First specify variables − it is easier to work with them PROCESSES=usrlocalindexProcessList HOSTS=usrlocalindexHostList REPORT=usrlocallogsReport ALIAS=chk_oper The starting timestamp echo \n\nThe script check_processes started on date \n | tee REPORT A single loop for all listed processes at all listed hosts for Host in cat HOSTS do for Process in cat PROCESSES do echo | tee −a REPORT echo Checking the host \Host\: | tee −a REPORT remsh Host binps −ef | eval grep Process devnull 21 if [ ? −eq 0 ] then echo The process \{Process}\ is running. | tee −a REPORT else echo The process \{Process}\ is missing. | tee −a REPORT fi 445 done The ending timestamp echo \n\nThe script \check_processes\ completed on date \n\n | tee −a REPORT To print the report uncomment the line lp REPORT To email the report uncomment the line mailx −s Process Status Report ALIAS REPORT To delete the report uncomment the line rm REPORT This is just an example to illustrate the strength of remshing. The rest of the example shows how to generate a comprehensive and effective report; of course, there are a number of other ways to do this.

19.3 Secure Shell SSH