Configuring the Remote Shell

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.

The rsh Command

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

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.

Make sure the file /etc/inetd.conf contains a line similar to the following. In particular, make sure the first character on this line is not a pound sign (#).

shell stream tcp nowait root /usr/sbin/tcpd in.rsh
If you make any changes to this file, you need to restart the inet daemon.

$ sudo /etc/init.d/inet restart

If your system uses the xinet daemon, perform the following steps to enable the remote shell command.

Edit the configuration file for the xinet daemon. The file that contains the information for the remote shell is /etc/xinetd.d/rsh. In this file, make sure the disable variable is set to "no".

$ cd /etc/xinetd.d

$ sudo editor rsh

disable = no
If you make any changes to this file, you need to restart the inet daemon.

$ 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.

The ssh Command

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

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.

On the local system, execute the ssh-keygen command to generate an authentication key for the secure shell. Press return to accept the default answers to the questions that are asked.

ssh-keygen –t rsa
The ssh-keygen command will create the files $HOME/.ssh/id_rsa and $HOME/.ssh/id_rsa.pub. The later file needs to be appended to the file $HOME/.ssh/authorized_keys2 on the remote system. The following commands will do this for you; however, they will prompt you for the password.

$ ssh remoteHost mkdir .ssh >& /dev/null

$ cat .ssh/id_rsa.pub | ssh remoteHost “cat >>.ssh/authorized_keys2”
If the secure shell still prompts for a password, make sure the files used by the secure shell on both the local and remote systems are only accessible by the user.

$ chmod 755 $HOME

$ chmod 700 $HOME/.ssh

$ chmod 600 $HOME/.ssh/id_rsa

$ chmod 600 $HOME/.ssh/id_rsa.publ
If the secure shell still prompts for a password, check its configuration file on the local system. You may need to add lines similar to the following in order to insure that it defaults to using version 2.0 of the secure shell protocol.

$ sudo editor /etc/ssh/ssh_config

Host *

Protocol 2,1

RSAAuthentication yes
If the secure shell still prompts for a password, check for errors in the system message file (e.g., /var/log/message) or use the –v option with ssh to have it print out information about what it is doing.