<OL>

<LI>User root on machine stingray?

<BR>

<BR></LI>

<LI>User root on machine manatee?

<BR>

<BR></LI>

<LI>User root on machine french-angel?

<BR>

<BR></LI>

<LI>User frank on machine dolphin?

<BR>

<BR></LI>

<LI>User frank on machine stingray?

<BR>

<BR></LI>

<LI>User frank on machine tarpon?

<BR>

<BR></LI>

<LI>User diane on machine manatee?

<BR>

<BR></LI>

<LI>User diane on machine dolphin?

<BR>

<BR></LI>

<LI>User diane on machine flying-gurnard?

<BR>

<BR></LI>

<LI>User rob on machine yellowtail?

<BR>

<BR></LI>

<LI>User rob on machine dolphin?

<BR>

<BR></LI>

<LI>User rob on machine manatee?

<BR>

<BR></LI>

<LI>User rob on machine flying-gurnard?

<BR>

<BR></LI></OL>

<P>Here are the answers:

<BR></P>

<OL>

<LI>Yes; rob's .rhosts file has an entry stingray root.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry manatee root. However, root from manatee could access flounder&#151;as root&#151;without a password, because manatee is listed in /etc/hosts.equiv.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry french-angel root.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry dolphin frank. However, frank from dolphin could access flounder&#151;as frank&#151;without a password, because dolphin is listed in /etc/hosts.equiv.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry stingray frank.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry tarpon frank.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry manatee diane. However, diane from manatee could access flounder&#151;as diane&#151;without a password, because manatee is listed in /etc/hosts.equiv.

<BR>

<BR></LI>

<LI>Yes; rob's .rhosts file has an entry stingray diane.

<BR>

<BR></LI>

<LI>No; rob's .rhosts file does not have an entry flying-gurnard diane.

<BR>

<BR></LI>

<LI>Yes; rob's .rhosts file has an entry yellowtail rob.

<BR>

<BR></LI>

<LI>Yes; the /etc/hosts.equiv file has an entry dolphin. Note that if the system administrator removed this entry, this answer would still be yes because of the dolphin rob entry in his .rhosts file.

<BR>

<BR></LI>

<LI>Yes; the /etc/hosts.equiv file has an entry manatee rob.

<BR>

<BR></LI>

<LI>No; the /etc/hosts.equiv file does not have an entry flying-gurnard nor does rob's .rhosts file have an entry flying-gurnard rob.

<BR>

<BR></LI></OL>

<H4 ALIGN="CENTER">

<CENTER><A ID="I16" NAME="I16">

<FONT SIZE=3><B>Using </B><B>rlogin</B>

<BR></FONT></A></CENTER></H4>

<P>If you need or wish to be logged in to a computer that is away from your current location, rlogin can help you. The rlogin application establishes a remote login session from your machine to another machine that is connected via the network. This 
machine could be next door, next to you on your desk, or even on a different continent. When you successfully execute an rlogin from your screen, whether it is a terminal, or one window of your graphical display, the shell that prompts you and the commands 

you enter are executing on the remote machine just as if you sat down in front of the machine and entered login.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I17" NAME="I17">

<FONT SIZE=3><B>Establishing an </B><B>rlogin</B><B> Connection</B>

<BR></FONT></A></CENTER></H5>

<P>The rlogin command takes a mandatory argument that specifies the remote host. Both the local and remote host must have rlogin available for a connection to be established. If this is the case, the local rlogin will connect to the specified remote 
machine and start a login session.

<BR></P>

<P>During a nonremote login, the login process prompts you for two things: your user name and your password. Your user name identifies you to the computer and your password authenticates that the requester is really you. During an rlogin, the rlogin 
protocol takes care of some (or even all) of this identification/authorization procedure for you. The rlogin protocol initiates the login session on the remote host for a particular user. By default, this user is the same as the local user (that is, you). 

In this case, you never have to type in your user name. However, if you wish to log in to the remote host as a different user, you may override the default user name by using the -l option to specify a user name.

<BR></P>

<P>The rlogin protocol may even take care of the authentication for you. If you (or your system administrator) have made the proper entry in the /etc/hosts.equiv or your $HOME/.rhosts file, no authentication is necessary (that is, you will not be prompted 

for your password). If these files do not have entries for your host and user name, a password prompt will be printed just like in a local login attempt.

<BR></P>

<P>Let's look at a few examples. Assume that your user name is rachel and the local machine to which you're logged in is called moray-eel. To log in as yourself on machine flounder you would enter this:

<BR></P>

<PRE>$rlogin flounder</PRE>

<P>The connection to flounder would take place, and a login session would be initiated for user rachel (and fail if user rachel doesn't exist on flounder). Next, the rlogin protocol checks the special files to see if authentication is necessary. If 
moray-eel is listed in the file /etc/hosts.equiv or in ~rachel/.rhosts, no authentication is needed.

<BR></P>

<P>To log in to flounder as user arnie you would enter rlogin -l arnie flounder.

<BR></P>

<P>Here the login session is initiated with the user name arnie. If user arnie exists on flounder, the special files are checked for authentication. Since the user name for the remote login is different than the local user name, the /etc/hosts.equiv file 
does not provide authentication. If the file ~arnie/.rhosts has an entry moray-eel rachel, no authentication is necessary (that is, login succeeds without password). If this entry does not exist, the password prompt will appear and you must enter the 
password associated with user arnie. This is not a prompt for your password.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I18" NAME="I18">

<FONT SIZE=3><B>Failed Connect</B>

<BR></FONT></A></CENTER></H5>

<P>Several things may go wrong when you try to connect to a remote machine via rlogin. Some of these are problems that are out of your control. In these instances, you should contact a system administrator to help you solve the problem.

<BR></P>

<P>In cases where authentication is necessary, you might enter the password incorrectly. If this happens, the result is the same as in a local login attempt. The login process lets you try again by prompting first for your user name and then your password. 

Note that this is the only situation in which you must supply your user name if you're trying to rlogin as yourself.

<BR></P>

<P>For most other problems you will need your system administrator's help. See the section &quot;Troubleshooting&quot; for ways to identify the cause of the problem. Any details about the problem symptoms will help the person who is responsible for fixing 

the problem. Some of the problems you might see are the following:

<BR></P>

<UL>

<LI>The user account does not exist on the remote.

<BR>

<BR></LI>

<LI>Your local host is not connected to the remote via the network.

<BR>

<BR></LI>

<LI>The remote host is down.

<BR>

<BR></LI>

<LI>The remote host does not support rlogin.

<BR>

<BR></LI>

<LI>The network between the local and remote hosts is having problems.

<BR>

<BR></LI></UL>

<H5 ALIGN="CENTER">

<CENTER><A ID="I19" NAME="I19">

<FONT SIZE=3><B>Using the Remote Login Session</B>

<BR></FONT></A></CENTER></H5>

<P>After a successful remote login, the rlogin protocol initiates your session using some information from your local session. This saves you the trouble of having to initialize your environment totally from scratch. Your terminal type (the value of the 
TERM environment variable) is propagated. Other information, such as baud rate and your screen (window) size, may also be propagated, depending on what the local and remote hosts support.

<BR></P>

<P>Then the login process proceeds as if you were actually directly connected to this machine. All of the information and files are taken from the remote. The remote password file contains the user account information, including the login shell to be 
executed and the starting (HOME) directory. All shell start-up files (found on the remote) execute, which further initializes your environment. When the start-up completes, the shell prompt you see is the shell that is running on the remote host.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> In some LAN environments, the network is configured such that your HOME directory is on a remote file server that is mounted on each machine you access. In this case, you actually have just one 
physical HOME directory, and thus just one set of dot files (for example, .login). This results in the same login environment for you on each machine. However, this makes writing your dot files a little more complicated because you need to take into 
account all the different machines to accommodate.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>Because the remote prompt and local prompt may look alike, you may wish to include <I>hostname</I> in your prompt variable (PS1). If you're ever in doubt about what host the shell prompt is coming from, 

use the <I>hostname</I> command.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>When you see the remote prompt, you can enter any commands you would in a local environment. The rlogin protocol transfers input and output between the local and remote hosts. This transfer is transparent to you. Sometimes you may notice slow 
performance, depending on the network speed and load.

<BR></P>

<P>During your remote session, you may want to access your local machine. You could just exit your remote session, at which point you would be back at your local prompt. But if you aren't finished using the remote, using exit followed by another rlogin, 
possibly multiple times, is tedious. There is a better way&#151;using the escape character.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I20" NAME="I20">

<FONT SIZE=3><B>Using the Escape Character</B>

<BR></FONT></A></CENTER></H5>

<P>The rlogin protocol provides an escape character that, when typed as the first character on the command line, is treated specially. The default escape character is the tilde (~) character, but you may change this on the rlogin command line via the -e 
option. If the character immediately following the escape character is one that the local rlogin process recognizes, it performs the function associated with this character. Otherwise the escape character (and the remaining characters) are executed on the 

remote.

<BR></P>

<P>The ~. character sequence is the command to disconnect from remote. This is not a graceful disconnect, as in an exit. It immediately disconnects from the remote. This should only be used when, for some reason, you are unable to execute the exit command.



<BR></P>

<P>If the local rlogin was executed by a job-control shell (C shell or Korn shell), then you can suspend the rlogin by the escape sequence <I>~susp</I>, where <I>susp</I> is your suspend control character, usually Ctrl+Z. This is very convenient. It saves 

the multiple exit followed by another rlogin sequence you would otherwise need for accessing the local machine. In a graphical user interface environment, having two windows&#151;one for the rlogin and one locally&#151;solves this problem as well.

<BR></P>

<P>It is possible to rlogin to one machine, then rlogin from there to another machine. You can use multiple escape characters to denote any one of the machines in this chain. As an example, say you are locally logged in to Host A. You are using a 
job-control shell with suspend set to Ctrl+Z. From Host A, you rlogin to Host B. From there you log in to Host C. And from there you rlogin to host D. At this point, everything you enter is going all the way to D to execute. In order to reach any host in 
the chain, just associate one escape character with each host. You must start with your local host, and then go in the same order as the rlogins. In this example, a single ~ refers to Host A, ~~ refers to Host B, ~~~ refers to Host C.

<BR></P>

<P>To suspend the rlogin from Host B to Host C you would type <I>~~^Z</I>. This will leave you in your original shell on Host B. In order to return to rlogin you would use the fg command as with any suspended process.

<BR></P>

<P>To disconnect the rlogin from Host C to Host D you would type ~~~..

<BR></P>

<P>One very common escape sequence, which is not supported on all platforms, is the shell escape, ~!. Typing this sequence causes the rlogin to give you a subshell on the machine that is referred to by ~. You can use multiple escape characters to denote 
any host within a chain of rlogins. To return to the rlogin, simply exit the subshell.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> There is a difference between <I>~susp</I> and ~!. The suspend command will put rlogin in the background and let you interact with your original shell (the one from which you ran rlogin). The shell 
escape will start a new shell as a child of rlogin. (See Figure 8.2.)

<BR></NOTE>

<HR ALIGN=CENTER>

<P>

<BR><B><A HREF="08unx02.gif">Figure 8.2. Processes for suspend and shell </B><B>escape.</A></B>

<BR></P>

<H4 ALIGN="CENTER">