The remsh and rsh commands, which are shorhand for "remote shell", can be used to login to a remote system or execute a command on a remote system. The syntax for the commands is as follows:
rsh [-n] [-l username] hostname command
rsh hostname [-n] [-l username] command
remsh [-n] [-l username] hostname command
remsh hostname [-n] [-l username] command
hostname [-n] [-l username] command
On Solaris systems, rsh and remsh can be used
equivalently. If you are using a Linux system, the rsh command
may be available, but not the remsh command. The Remote Shell
service is even available for Windows systems from Microsoft's Resource
Kit (see
Adding R* to Windows NT by Robert Flannigan). Or commercial
versions are available for Windows 95 and later from
Denicomp Systems (you can download
a time-limited evaluation version).
The following options are supported for rsh and remsh:
-l username
Uses username as the remote username instead of your
local username. In the absence of this option, the
remote username is the same as your local username.
-n Redirects the input of rsh to /dev/null. You sometimes
need this option to avoid unfortunate interactions
between rsh and the shell which invokes it. For exam-
ple, if you are running rsh and invoke a rsh in the
background without redirecting its input away from the
terminal, it will block even if no reads are posted by
the remote command. The -n option will prevent this.
The remsh and rsh commands connect to the specified hostname and
execute the specified command. If no command is entered, i.e.
you use rsh hostname or remsh hostname, you will
be logged into the remote system. The type of remote shell (bash, sh, rsh, or
other) is determined by the user's entry in the file /etc/passwd on the
remote system.
If you have an account on the remote system with the same userid as the account you are currently using on the local system, you will be prompted for the password for the remote system and, when the correct password is supplied, will receive a shell prompt on the remote system where you can enter commands on the remote system.
bash-2.03$ remsh 192.168.1.6
Password:
Last login: Tue Oct 10 17:07:07 on console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
You have new mail.
-bash-3.00$
If you include a command to be executed, then you must have permission to remotely execute commands. Otherwise you will get a "permission denied" response from the remote system.
bash-2.03$ remsh 192.168.1.6 uname -a
permission denied
To grant permission for the remote command execution, you can create a
.rhosts file in the home directory of the user account on the remote
system that specifies the hostnames of the systems from which
remote commands can be submitted. For instance, you could put a line with the
hostname mypc.abcd.com in the .rhosts file, if you wanted
to allow commands to be remotely submitted from the system mypc.abcd.com. If
you want to allow connections from multiple systems, put them on separate lines.
-bash-3.00$ cat .rhosts
mypc.abcd.com
mac2.abcd.com
With the above .rhosts file on the remote system, you will be able
to login to the remote system from either mypc.abcd.com or mac2.abcd.com or
submit commands remotely with rsh remotesys or remsh
remotesys given that the remote system you want to log into is named
remotesys and you have the same userid on both systems. You won't need to
enter a password, even if the password on the local system differs from
the password for the remote system.
You can also execute commands on the remote system and see the output on the local system.
E.g.
bash-2.03$ remsh 192.168.1.6 uname -a
SunOS hofud 5.10 Generic i86pc i386 i86p
Be sure to use the command chmod 600 .rhosts after you
create the .rhosts file so that others can not view its contents.
Shell metacharacters that are not quoted are interpreted on the local host; quoted metacharacters are interpreted on the remote host.
E.g.
remsh remotehost cat remotefile >> localfile
will append the remote file remotefile to the local file
localfile, while the command line
remsh remotehost cat remotefile ">>" otherremotefile
appends remotefile to the remote file otherremotefile.
If you wish to login using a different userid, e.g. jsmith on the remote system,
then you can use the -l option to specify a userid other than
the one you are logged in under on the local system. You will be prompted for
the password for that account.
# remsh -l jsmith 192.168.1.6
Password:
You won't be able to remotely execute commands, however, if you are using
an account that doesn't match the userid on the remote system even with the
-l option, if that account is not listed in the
.rhosts file. You will get a "permission denied" error.
# remsh -l jsmith 192.168.1.6 uname -a
permission denied
You can fix that problem by adding the account to the rhosts file. For instance, suppose I am logged into the root account on the local system, but I want to execute a command on the remote system as the user jsmith. I can edit the .rhosts file on the remote system to contain the following 2 lines.
-bash-3.00$ cat .rhosts
mypc.abcd.com
mypc.abcd.com root
Now, supposing I have a userid jsmith on both systems that is my regular user account, I can execute commands while logged into the local system as jsmith or root. The first line in the .rhosts file doesn't have any username specified, so it will cover instances where the userid matches on both systems. The second line will allow me to specify commands to be run under the jsmith account on the remote system while I am logged into the local root account as shown below.
# remsh -l jsmith 192.168.1.6 pwd
/home/jsmith
As an alternative to using an .rhosts file in the home directory
of an individual account on the remote system, you can create a
hosts.equiv account in the /etc directory of the remote
system, if you have root access on that system. Again, you should change
the protection on the file after you have created it with
chmod 600 /etc/hosts.equiv, so that not everyone on the system
can read its contents.
You would use the same type of entries in that file as in the .rhosts file. E.g., to allow user jsmith to connect from mypc.abcd.com, you would would have the following /etc/hosts.equiv file.
# cat /etc/hosts.equiv
mypc.abcd.com jsmith
When you use rsh or remsh to remotely login to
a system, you will be connected to
TCP port 513.
E.g., if you issued the command
remsh 192.168.1.6 from the system with IP address 192.168.1.1,
you would see the following connection established.
-bash-3.00$ netstat -an | grep 51[34] | grep ESTABLISHED
192.168.1.6.513 192.168.1.1.1023 8760 0 49640 0 ESTABLISHED
The source system is 192.168.1.1 and it has a connection to port 513 on 192.168.1.6. The source port on 192.168.1.1 is 1023.
If you are specifying a command with the rsh or remsh
commands, then a TCP connection is established to port 514 on the remote system.
You can confirm that connection by using the sleep command.
# remsh -l jsmith 192.168.1.6 sleep 180
The above command will execute the sleep command on the remote
system using the jsmith account to execute the command. The argument of
180 tells the sleep command to suspend execution for 180 seconds. I.e. it
justs pauses for 3 minutes.
If you were logged into the remote system in another window, you could then check network connections. This time, instead of a connection to port 513, there is one to TCP port 514. Again the source system from which the sleep command was submitted is 192.168.1.1 and the remote system is 192.168.1.6.
bash-3.00$ netstat -an | grep 51[34] | grep ESTABLISHED
192.168.1.6.514 192.168.1.1.1023 8760 0 49640 0 ESTABLISHED
Keep in mind that rsh and remsh don't encrypt
any of the data flows. Though you may not be entering passwords when you
have access permitted through an .rhosts or /etc/hosts.equiv
file, the input and output is in clear text, i.e. can possibly be viewed by
others on the network. The SSH
and scp commands
are secure alternatives, since they encrypt userids, passwords, and all data
between the remote and local systems.
References:
