This document describes how to insure that remote shell is working correctly, and that it will not prompt you for a password. Not prompting for the password is useful if you need to execute remote commands from a shell script, but be careful, this may leave your system vulnerable to unauthorized access.
In the following discussion, the local system refers to the system where the remote command originates, and the remote system is the system where the command will be executed.
This section describes how to insure that the rsh and rcp commands are working, and that they do not require a password when they are used. Log in as the user that will execute the commands (this discussion assumes that the same user will execute the commands on both systems) and execute the following command. If it works without prompting for a password, then both the rsh and rcp commands are working correctly.
$ rsh remoteHost echo foo
If this command fails with a “permission denied” error, make sure the remote shell is enabled on the remote system. If your system uses the inet daemon, you do this by performing the following steps.
shell stream tcp nowait root /usr/sbin/tcpd in.rsh
$ sudo /etc/init.d/inet restart
If your system uses the xinet daemon, perform the following steps to enable the remote shell command.
$ cd /etc/xinetd.d
$ sudo editor rsh
disable = no
$ sudo /etc/init.d/inet restart
If you still get a “permission denied” error, make sure the file /etc/hosts.deny on the remote system does not contain an entry for the local system.
If the command prompted for a password, then on the remote system, check the files /etc/hosts.equiv and $HOME/.rhosts. These files are used to make systems appear to be administratively equivalent. A user on one system is assumed to be the user with the corresponding name on another system. Make sure both these files exist and contain the names of the systems where the remote commands originate. Also, make sure the .rhosts file is owned by the user.
If the command keeps prompting you for the password (i.e., it appears that you entered the password incorrectly) and you are trying to execute the remote command as the super user, then on the remote system, check the file /etc/securetty. This file is used to restrict which terminals the super user is allowed to use when logging into the system. To remove these restrictions, you can temporarily rename this file to something such as /etc/securetty.bak.
This section describes how to insure that the secure shell commands ssh and scp are working, and that they do not require a password when they are used. Log in as the user that will execute the commands and execute the following command. If it works without prompting for a password, then both the ssh and scp commands are working correctly.
$ ssh remoteHost echo foo
If this command resulted in a “command not found” error, either your PATH environment variable is not set correctly to find these commands, or more likely, they are not installed on your system. If this is the case, you will need to install the secure shell on the systems you will be using.
The following instructions assume that you are using version 2.0 of the secure shell protocol. You can determine which version of the protocol your secure shell supports by looking at its version banner.
$ ssh –V
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
The following instructions describe the steps that allow the secure shell to no longer require a password.
ssh-keygen –t rsa
$ ssh remoteHost mkdir .ssh >& /dev/null
$ cat .ssh/id_rsa.pub | ssh remoteHost “cat >>.ssh/authorized_keys2”
$ chmod 755 $HOME
$ chmod 700 $HOME/.ssh
$ chmod 600 $HOME/.ssh/id_rsa
$ chmod 600 $HOME/.ssh/id_rsa.publ
$ sudo editor /etc/ssh/ssh_config
Copyright © 2002 by Bruce Blinn