# this is pigeon:/home/gps/.rhosts
trix.dircon.co.uk root
trix.dircon.co.uk gps
trix.lan67.priv root
trix.lan67.priv gps

rlogin, rsh and rcp use the same mechanism, hence the same files. If the requesting host or user, isn't in .rhosts, rlogin presumes itself to be interactive, and offers a password prompt, whereas rcp simply fails (if not configured).

Personally, I believe that this mechanism is SAFER, because once you have established the basic user-login identity, you can permit them to do certain functions without telling them the passwords of other systems. They don't need a weekly newsletter, they don't write it down anywhere, they don't shout it out across the room, and they don't forget it. Service down is itself a problem.

The original login can have a nice menu so that the user may not even be aware of what is happening.

Gives you a login on pigeon. Just like telnet, but without passwords.

If you do require a password, rlogin asks for it, so it is usually a safe option in scripts.

rsh however fails if you need a password.

Run the remote shell on pigeon as the user login gps with the commands to mount the cdrom (with "defaults,user" in /etc/fstab). You can do this as a safer user, not root.

You should still set the permission on the device for the eject command.

If rlogin needs a password, it asks for it, but rsh just fails.

There may be a bug, where the remote command exits, and the remaining TCP/IP buffers get truncated. If so, you will need to sleep to wait for the buffers to get sent.

Some older systems, may put a welcome banner at the top of the rsh return text, in which case you have to script around it.

This copies the file from pigeon to here, but the command is flexible.

rcp scans its arguments, and can copy between several different hosts, as different users. It can transfer multiple files to a directory, and can recursively copy a subdirectory. Beware of permissions (eg mtime of file) and transferring symbolic links, which become files not links.

If you set the SHELL parameter in the remote /etc/password, that program will be used instead of /bin/sh. That program can be a #!/bin/sh shell script or a perl, tcl or other shell script, or even a compiled program.

This replacement program would not then simply run the requested command. Instead it would look at the command line, and decide if it is an allowed command, then run it. This would make it that much harder for a hacker to do anything interesting, and still allow you to do exactly what your application wants.

If the requested command is rcp, and you wish to allow that, simply exec rcp.

The rcp program, calls rcp at the remote end, and they have their own protocol to pass multiple parameters around, and a result code back. It can do this over a single TCP/IP stream, using it's own protocol to distinguish commands, data and return codes.

rsh, however uses a single TCP/IP stream, and expects a program like /bin/sh on the other end. Since /bin/sh has no knowledge of rcp/rsh, there is no built-in method of returning the exit code of the the called shell. This means that the result code from rsh (exit 0 means ok, else errno) only tells you that rsh suceeded in making the call, or failed to make the call.

If your called command line fails, its exit code is dropped, and you get '0' back from rsh - because the call succeeded. This is a real headache, as you will have to write your own workaround to get the result. Not a problem for occasional commands run manually.

-NOTE- 'rsh' is the 'remote-shell' command. The 'restricted-shell' command coincidentally has the same name. --

The main security feature in .rhosts is the name of the calling host, written in $HOME/.rhosts. This must match the FIRST name on the line in /etc/hosts (unless you are using NIS).

The /etc/hosts file must be secure (not writable, but world readable). Also check the permissions on the /etc/ and / directories.

The calling host must be secure. The calling LAN must be secure. The local cracker's route in is to plug a Linux box on the LAN, wait for the secure host to go off-line for a few seconds, and pretend to be it for long enough to run a single command.

Basically don't allow it as root, only allow it as a special user, who has a special shell, maybe a chroot'ed /etc/passwd, and use an 'at' or cron job to process results before/after connections.

However for home LAN's they are nice!

echo '' >> $HOME/tmp/email_list_7

However, when using rsh, the command line has be re-quoted to get through multiple-evaluation stages. It's easiest to avoid the NEED for quoting anywhere, write a script that contains the ' " < & or anything else that would need special quoting.

You could even put the command into a script, rcp the script over, run it and delete it.

This does not work, but almost does, (it is supposed to). It writes a message in /var/adm/messages