If the calling user and host is KNOWN and is in a controlled file, why not all remote access without passwords? The paranoid should read this because not doing it doesn't stop someone else!
# this is pigeon:/home/gps/.rhosts trix.dircon.co.uk root trix.dircon.co.uk gpsrlogin, rsh and rcp use the same mechanism, hence the same files, but 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 security 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.
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 several 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 (as files not links).
If you set the SHELL parameter in the remote /etc/password, that program will be used instead of /bin/sh. You can substitute 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 what your application wants
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.
rsh, however expects a program like /bin/sh on the other end, and has 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.
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 should be the FIRST name on the line in /etc/hosts (otherwise strcmp doesn't match).
The /etc/hosts file must be secure (but world readable), so the /etc/directory, and the / directory must be.
The calling host must be secure. The calling LAN must be secure. The local 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 IP_MASQUERADE as it for long enough to run a single command.
Basically don't allowit 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 '<user@host>' >> $HOME/tmp/email_list_7The '<' and '>' won't confuse the local shell, because they are quoted, but may effect one of the shells along the way. Use STDIN to transfer non trivial command lines, (or rcp).
This does not work, but almost does, it writes a message in /var/adm/messages