MoonPoint Support Logo

 


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals



Advanced Search
November
Sun Mon Tue Wed Thu Fri Sat
     
29    
2006
Months
Nov


Wed, Nov 29, 2006 9:01 pm

remsh and rsh

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:

  1. rsh or remsh Command
  2. Unix Manual Page for remsh
  3. Configuring .rhosts
  4. hosts.equiv, rhosts
  5. remsh(1)
  6. hosts.equiv(4)
  7. remsh and the port number ?
  8. UNIX Shell Metacharacters
  9. Adding R* to Windows NT
    By Robert Flanagan

[/os/unix/commands] permanent link

Once You Know, You Newegg AliExpress by Alibaba.com

Shop Amazon Local - Subscribe to Deals in Your Neighborhood

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo