From: http://home.comcast.net/~lafeyette_management/KludgeKollection/rsh-rlogin_enable-LINUX.HOWTO
How to turn on RSH and RLOGIN with RedHat 7.3 in three easy steps
Become Root.
1. HOSTS.ALLOW and HOSTS.DENY
A. In /etc/hosts.deny, please the following line: ALL : ALL This should be the only line in the /etc/hosts.deny file. It will keep out unwanted intruders. B. In /etc/hosts.allow, please add the following: in.rshd : 192.168.0. in.rlogind : 192.168.0. portmap : 192.168.0. sshd : 192.168.0. Note that we are using the OPENSSH provided with RedHat. It is tcp-wrapped and therefore requires an entry in the /etc/hosts.allow file. Note: The default hosts.allow file provided at atlas:/root/bin contains "ALL: 127.0.0.1, 192.168.0., 192.168.1." which will include the above. It's a bit easier to write, but since it doesn't specifically enumerate the services to allow, it is somewhat less secure. Note also: As /etc/hosts.allow overrides /etc/hosts.deny, we are first setting a filter that denies EVERYONE access to the machine, and then, with /etc/hosts.allow, we are allowing only machines on the 192.168.0. network to access the services specified.
2. ALLOWING RSH/RLOGIN without a password.
In order to allow rsh/rlogin without passwords, we must place the hostnames of
all machines which are to be allowed passwordless access in the
/etc/hosts.equiv
file on the machine(s)) which is allowing such access. If, for example, we wish
to allow unrestricted access between two machines, liberty and compton, through
RSH, we would need to place appropriate /etc/hosts.equiv files on each machine.
As another example, if we wish to allow unrestricted access for Steven to Hablar
(his machine) from atlas, or cluster/compute nodes or other workstations, we need
to place the names of the machines (or the groups from /etc/netgroup ) that include
the involved machines) into the /etc/hosts.equiv file.
NOTE: If /etc/hosts.equiv is missing or incorrect, Steven won't be able to rsh to
his machine without a password!
=============================================================================
WHEN RSH <remote host> <command-string> returns "Permission denied"....
=============================================================================
If Compton wishes to RSH to Liberty and execute a command such as this one:
rsh liberty "mysql -B -u stupid -e ' show databases;'"
and COMPTON (Yes, I said COMPTON) lacks an appropriate /etc/hosts.equiv file,
then LIBERTY will get a "Permission denied" error. This isn't that
permission to execute the command is denied, but rather than permission is
being denied by COMPTON to the command's effort to return the results to
Compton through RSH. Think of this as something like sending your child
to the neighbor to borrow a cup of sugar: The child goes to get the sugar, and
the neighbor gives the sugar to the child and then send her back home, but,
though some act of gross neglect, you have forgotten that the door to your
home was locked, so the child cannot get back in to give you the cup of sugar.
==============================================================================
3. MAKING IT ALL WORK: TURNING ON THE RSH/RLOGIN DAEMONS.
In order for all the above to work, we must configure /etc/xinetd.d/rsh and /etc/xinetd.d/rlogin so that these daemons will be started when someone tries to rsh or rlogin to the host. Edit (SEE **NOTE below!!) the /etc/xinetd.d/rsh and the /etc/xinetd.d/rlogin service scripts in /etc/xinetd.d so that the value "disable = yes" is set to "disable = no" This can be accomplished with the chkconfig utility, e.g. chkconfig --level 345 rsh on chkconfig --level 345 rlogin on (Don't forget to do BOTH files, not just rsh.) Now, finally, restart xinetd with /usr/sbin/xinetd There ya go!!! 4 MAKING IT ALL WORK FOR ROOT !!!! CAUTION !!!! THIS PROCEDURE GIVES ROOT ACCESS WITHOUT A PASSWORD. THIS IS EXTREMELY INSECURE AND CONSTITUTES A SECURITY HOLE THE SIZE OF THE GRAND CANYON. A mischevous user LOGGED IN AS ROOT at machine A, such that machine A's name appears in .rhosts (or .shosts for ssh) on machine B will be able to execute any command or program on machine B AS ROOT ON MACHINE B!!! This can be about as safe as sleeping with an armed nuclear weapon. So don't do this without fully understanding the security ramifications. Did you read the caution above? Huh? Didja? Well, go back and read it again. Okay, now that THAT's done, and you still want to do this (Butthead!), here's how: For the sake of clarity, we will assume we are discussing two machines, Liberty and Compton, and that we wish to be able to rsh from Liberty to Compton as root without having Compton deny access or ask us for a password. Become root on Compton. A. In /root (root's home directory), create a file called .rhosts. B. Place "liberty" in the .rhosts file (without the double-quotes). C. You may wish to place the names of other machines that are to have root access to compton in this file as well, one name per line. D. Add a line containing "rsh" and a line containing "rlogin" to /etc/securetty. E. If you wish ssh access to compton to be similarly unrestricted, then you may follow the above procedure, except name the file .shosts instead of .rhosts. Note that you must BE root on one of the machines in the .rhosts file on the target machine before you can login as root on the target machine without a password. If you try to do rlogin compton -l root whilst logged in to liberty as someone other than root, you will not be permitted access. This, at least, provides a modicum of securetty (pun/mispelling intended.) That's it. Have fun. Don't blame me if you lose your job over this. Now, go back and read the Caution again. APPENDIX: 1. Sample HOSTS.ALLOW and HOSTS.DENY # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # in.rshd : 192.168.0. in.rlogind : 192.168.0. portmap: 192.168.0.0/255.255.255.0 ALL: 192.168.1.0/255.255.255.0 ALL: 192.168.0.0/255.255.255.0 sshd: 192.168.0. # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! ALL : ALL 2. Sample HOSTS.EQUIV compton atlas unity liberty montpellier orsolino 3. Example of /etc/xinetd.d/rsh and /etc/xinetd.d/rlogin (modified to enable these services.) # default: on # description: The rshd 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. service shell { socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rshd -h disable = no } # default: on # description: rlogind is the server for the rlogin(1) program. The server / # provides a remote login facility with authentication based on / # privileged port numbers from trusted hosts. service login { socket_type = stream wait = no user = root log_on_success += USERID log_on_failure += USERID server = /usr/sbin/in.rlogind disable = no } (Note that I left the original descriptive text in these files untouched, so you can see that they are indicated to be enabled, when, in fact, they are disabled; i.e. the "disable = no" line reads "disable = yes" in their original form. See **NOTE below for more on this.) 4. SAMPLE /ETC/SECURETTY with rsh and rlogin added at the bottom. (Go read that Caution again in section 4 above before you enable root access!!!!) vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 vc/7 vc/8 vc/9 vc/10 vc/11 tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 rsh rlogin ** Note: The description text at the beginning of the rsh and rlogin scripts both claim that the service's default status is "on", when, in fact, it is "off". Don't make the mistake of doing "head /etc/xinetd.d/rsh", and then believing the service is already on just because the description says it is. (Head only displays the first 12 lines, and the "disable" parameter for the service is locate around line 14 or 15, therefore, you won't see it--and won't see that the service is really turned off.)