Chapter 9 Using the Network

A network is a group of computers set up to communicate with one another. When your machine is part of a network, you have the opportunity to use the resources of other machines on the network while remaining logged in to your own machine. You can log in to other machines or you can execute remote commands that affect other machines from your own workstation.

This chapter describes the following topics.

• Networking Concepts

• Logging In Remotely (rlogin)

• Copying Files Remotely (rcp)

• Executing Commands Remotely (rsh)

• Viewing User Information (rusers)

• Running Networked Applications

If your machine is not currently attached to a network, the information presented here might not be relevant to your situation. However, it might be valuable for you to review this information to get an overall view of the benefits that networking can provide.

Networking Concepts

A network connection between machines enables these systems to transmit information to one another. The following list describes the more common network types.

• Local area network (LAN) — A network that ranges over a small area, generally less than a few thousand feet

• Wide area network (WAN) — A large network that can span thousands of miles

• Campus area network (CAN) — An intermediately sized network

A network that is composed of a linked group of networks is called an internetwork. For example, your machine might be part of a network within your building and part of an internetwork that connects your local network to similar networks across the country. Because the difference between a network and an internetwork is generally invisible to the user, the term network is used in this guide to refer to both networks and internetworks.

Networked machines use a network protocol, or common network language, to communicate. A network protocol ensures that information is transmitted to the appropriate location on the network. An internetwork protocol, sometimes referred to as a relay, links networks together.

Logging In Remotely (rlogin)

The rlogin command enables you to log in to other UNIX machines on your network.

To remotely log in to another machine, type the following command.

$ rlogin  machinename

In the previous example, machinename is the name of the remote machine.

If a password prompt appears, type the password for the remote machine and press Return. If your machine name is in the other machine's /etc/hosts.equiv file, the current machine does not prompt you to type the password.

venus$ rlogin starbug -l user2
Password: 
Last login: Wed Nov  1 13:08:36 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
venus$ pwd
/home/user2
venus$ logout
Connection closed.
venus$

rlogin Without a Home Directory

In the previous example, user user2 logs in to the remote machine starbug at the directory /home/user2, as indicated by the pwd command. When you log in to a machine where you have no account, rlogin displays a message stating that you have no home directory on the remote machine. rlogin then logs you in to the root (/) directory of that machine:

venus$ earth -l user2
Password:
No directory! Logging in with home=/
Last login: Thu Nov  2 12:51:57 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
earth$ pwd
/
earth$ logout
Connection closed.
earth$

rlogin as Someone Else

The -l option of the rlogin command enables to log in to a remote machine as someone else. This option can be useful if you are working on someone else's machine (using their username) and you want to log in to your own machine as yourself.

Use the following command syntax for the -l option of the rlogin command.

# rloginmachinename -l username  

The following example shows how user user2 on machine venus would log in to machine starbug as user1.

venus$ rlogin starbug -l user1
Password:
Last login: Thu Nov  2 12:51:57 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
starbug$ pwd
/home/user1
starbug$ logout
Connection closed.
starbug$

Note that when you log in to a remote machine as someone else, you are placed in that user's home directory.

rlogin to an Unknown Machine

If you try to log in to a remote machine unknown to your machine, rlogin searches unsuccessfully through the hosts database and then displays the following message.

$ rlogin stranger
stranger: unknown host
$

Aborting an rlogin Connection

Normally you terminate an rlogin connection by typing logout at the end of a work session. If cannot terminate a session in this manner, you can abort the connection by typing a tilde character followed by a period (~.). The remote login connection to the remote machine is aborted and you are placed back at your original machine.

If you log in to a series of machines, gaining access to each machine through another machine, and you use ~. to abort the connection to any of the machines, you are returned to your original machine.

venus$ rlogin starbug -l user2
Password:
Last login: Thu Nov  2 15:13:10 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
starbug$ ~.  (You may not see the ~ on the screen.)
Closed connection.
venus$

If you want to back up to an intermediate rlogin connection, use two tildes followed by a period (~~.).

venus$ rlogin starbug -l user2
Password:
Last login: Thu Nov  2 15:14:58 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
starbug$ rlogin rlogin earth -l user2
Password:
Last login: Thu Nov  2 15:24:23 from starbug
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
earth$ ~~.  (You may not see the ~~ on the screen.)
Closed connection.
starbug$

Suspending an rlogin Connection

When you want to suspend an rlogin connection so you can return to it later, type the tilde character (~) followed by Ctrl-Z. The rlogin connection becomes a stopped process and you are placed back at the machine from which you logged in.

To reactivate the connection, type fg. You can also type the percentage sign (%) followed by the process number of the stopped process. If you do not specify a process number, % activates the process most recently suspended.

venus$ rlogin goddess -l user2
Password:
Last login: Thu Aug 31 14:31:42 from venus
Sun Microsystems Inc.   SunOS 5.9       Generic February 2002
goddess$ pwd
/home/user2
goddess$~^Z

Stopped (user)
venus$ pwd
/home/user2/veggies
venus$fg
rlogin goddess
goddess$ logout
venus$

You can also type two tildes and press Ctrl-Z to suspend the current rlogin and place you at an intermediate rlogin.

For more information on the rlogin(1) command, refer to the man Pages(1): User Commands.

Verifying Your Location (who am i)

After logging in to a variety of remote machines, you might need to verify where you are. Type who am i to display the name of the machine you are currently logged in to as well as your current login name.

Copying Files Remotely (rcp)

The rcp command enables you to copy files from one machine to another. This command uses the remote machine's /etc/hosts.equiv and /etc/passwd files to determine whether you have unchallenged access privileges. The syntax for rcp is similar to the command syntax for cp.

To copy subdirectories and their contents from one machine to another, use rcp -r.

Copying Files From a Remote Machine

To copy from a remote machine to your machine, use the rcp command with the following syntax.

$ rcp machinename:source destination

In the previous example, machinename is the name of the remote machine, source is the name of the file(s) you want to copy, and destination is the path name on your machine where you want the copied file(s) to reside.

The following example illustrates how to copy the file /etc/hosts from the remote machine starbug to the /tmp directory on the local machine venus.

venus$ rcp starbug:/etc/hosts /tmp

You can also combine various abbreviations and syntaxes when using rcp. For example, to copy all of the files ending in .doc from user hank's home directory on remote machine fretful to the current directory on local machine venus, type the following command.

venus$ rcp fretful:~hank/*.doc .
venus$

Copying Files From Your Machine to Another

To copy files from your local machine to a remote machine, use the following command syntax.

$ rcp source machinename:destination

In the previous example, source is the file(s) you want to copy, machinename is the name of the remote machine, and destination is the path name on the remote machine where you want the copied file(s) to reside.

The following example illustrates how to copy the file newhosts from your /tmp directory to the /tmp directory on the remote machine starbug.

venus$ cd /tmp
venus$ rcp newhosts starbug:/tmp
venus$

For more information on the rcp(1) command and its options, refer to the man Pages(1): User Commands.

Executing Commands Remotely (rsh)

The rsh command (for remote shell) enables you to execute a single command on a remote machine without having to log in to the remote machine. If you know you only want to do one thing on a remote machine, rsh enables you to quickly execute one command on a remote machine.

To execute a command on a remote machine, use the following command syntax.

rsh machinename  command 

The following example shows how you would view the contents of the directory /etc/skel on the machine starbug.

venus$ rsh starbug ls /etc/skel*
local.cshrc
local.login
local.profile
venus$ 

Similar to the rlogin and rcp commands, rsh uses the remote machine's /etc/hosts.equiv and /etc/passwd files to determine whether you have unchallenged access privileges to the remote machine.

For more information on the rsh(1) command and its options, refer to the man Pages(1): User Commands.

Viewing User Information (rusers)

The rusers command (for remote users) shows you which users are logged in to other machines on your network. Type the rusers command by itself to display each machine on the network and the user(s) logged in to these machines.

$ rusers
starbug          user2 user1 root
earth            user1
venus					user3

Notice that three users are logged in to the machine starbug.

To display information on a specific remote machine, type the rusers command followed by the name of the machine.

$ rusers starbug
starbug          user2 user1 root
$

The -l option to the rusers command displays the following information.

• User names

• Machine and terminal names

• Time each user logged in

• How long each user has been idle (if more than one minute)

• Name of the machine that each user logged in from

$ rusers -l starbug
root       starbug:console       Oct 31 11:19         (:0)
user2      starbug:pts/7         Oct 31 11:20   40:05 (starbug)
user1      starbug:pts/13        Nov  1 14:42   17:18 (starbug)
$

You can also use the -l option without providing a machine name.

For more information on the rusers(1) command and its options, refer to the man Pages(1): User Commands.

Running Networked Applications

Normally, all the applications on your system are programs that are running on your local machine. However, if your workstation is part of a network, you can run applications on another machine and display them on your local screen. Running an application on another machine saves computing cycles on your local machine, and gives you access to an entire network of applications.

This section describes how to run an application on a remote machine and display it on your local screen. See More About Security for additional information on the complexities of running networked applications.

The process for running a networked application in your computing environment might vary.

Using rlogin to Run a Networked Application

To use the following procedure to run a remote application, you must meet these requirements.

• You must have access rights to the remote machine.

• Your home directory must be NFS-mountable on the remote machine.

• The application and appropriate libraries must be installed on the remote machine.

Contact your system administrator if you do not understand these requirements.

To run a networked application on a remote machine, set your environment variables with the following values.

• Set the DISPLAY environment variable in your shell on the remote machine to your local screen.

• Enable the remote machine to display the application program on your local machine. To enable this display access on the local machine, use the xhost command:

  $ xhost +remote_machine_name

The following procedure describes how to run an application on a remote machine with the rlogin command.

How to Run an Application on a Remote Machine

1. Use the xhost command on the local machine to give the remote machine display access.

   starbug$ xhost + venus

2. Log in to the remote machine.

   starbug$ rlogin venus -l user2 Password: Last login: Wed Nov 1 16:06:21 from starbug Sun Microsystems Inc. SunOS 5.9 Generic February 2002

3. Set the DISPLAY variable to the local machine.

   venus$ DISPLAY=starbug:0.0

4. Export the DISPLAY variable to the local machine.

   venus$ export DISPLAY

5. Run the application.

   venus$ bigprogram &

Even though you interact with this application just as you would with any other application on your screen, the application runs on the remote machine.

The benefit from running an application in this way is that it uses fewer computing resources than an application that is installed on your machine. This example shows how to run any remote application to which you have access.

More About Security

This section describes some fundamentals of network security that you might find useful as you run applications across the network, including:

• User-based and host-based access control mechanisms

• The MIT-MAGIC-COOKIE-1 and SUN-DES-1 authorization protocols

• When and how to change a server's access control

• How to run applications remotely, or locally as a different user

Who Should Read this Section

You do not need to change the default security configuration in the Solaris operating environment, at minimum, unless you run applications on a remote server.

Access Control Mechanisms

An access control mechanism controls which clients or applications have access to the X11 server. Only properly authorized clients can connect to the server. All other clients are denied access, and are terminated with the following error message.

Xlib: connection to hostname refused by server
Xlib: Client is not authorized to connect to server

The connection attempt logs to the server console as:

AUDIT: <Date Time Year>: X: client 6 rejected from IP 129.144.152.193 
   port 3485	Auth name: MIT-MAGIC-COOKIE-1

Two different types of access control mechanisms are used: user based and host based. That is, one mechanism grants access to a particular user's account, while the other mechanism grants access to a particular host, or machine. Unless the -noauth option is used with Xsun, both the user-based access control mechanism and the host-based access control mechanism are active. For more information see Manipulating Access to the Server.

User-Based Access

A user-based, or authorization-based, mechanism allows you to give access explicitly to a particular user on any host machine. The user's client passes authorization data to the server. If the data match the server's authorization data, the user is allowed access.

Host-Based Access

A host-based mechanism is a general-purpose mechanism. This type of mechanism enables you to give access to a particular host, in which all users on that host can connect to the server. A host-based mechanism is a weaker form of access control. If the host has access to the server, all users on that host are allowed to connect to the server.

The Solaris environment provides the host-based mechanism for backward compatibility.

Relink clients that are linked with older versions of Xlib or libcps to enable them to connect to the server with the new user-based access control mechanism.

Authorization Protocols

Two authorization protocols are supported in this version of the Solaris operating environment: MIT-MAGIC-COOKIE-1 and SUN-DES-1. They differ in the authorization data used. The protocols are similar in the access control mechanism used. The MIT-MAGIC-COOKIE-1 protocol that uses the user-based mechanism is the default in the Solaris operating environment.

MIT-MAGIC-COOKIE-1

The MIT-MAGIC-COOKIE-1 authorization protocol was developed by the Massachusetts Institute of Technology. At server startup, a magic cookie is created for the server and the user who started the system. On every connection attempt, the user's client sends the magic cookie to the server as part of the connection packet. This magic cookie is compared with the servers' magic cookie. The connection is allowed if the magic cookies match, or denied if they do not match.

SUN-DES-1

The SUN-DES-1 authorization protocol, developed by Sun Microsystems, is based on Secure Remote Procedure Call (RPC) and requires Data Encryption Standard (DES) support. The authorization information is the machine-independent netname, or network name, of a user. This information is encrypted and sent to the server as part of the connection packet. The server decrypts the information and, if the netname is known, allows the connection.

This protocol provides a higher level of security than the MIT-MAGIC-COOKIE-1 protocol. No other user can use your machine-independent netname to access a server, but another user can use the magic cookie to access a server.

This protocol is available only in libraries in the Solaris 1.1 and compatible environments. Any applications built with static libraries cannot use this authorization protocol.

Allowing Access When Using SUN-DES-1 describes how to allow another user access to your server by adding that person's netname to your server's access list.

Changing the Default Authorization Protocol

You can change the default authorization protocol, MIT-MAGIC-COOKIE-1, to SUN_DES-1, the other supported authorization protocol, or to no user-based access mechanism at all. You can change the default authorization protocol by editing the Xsun line in the /usr/dt/config/Xservers file. For example, to change the default from MIT-MAGIC-COOKIE-1 to SUN-DES-1, add the -auth sun-des option to the Xsun command by editing the following line in the /usr/dt/config/Xservers file.

:0  Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -auth sun-des 

If you must run the Solaris operating environment without the user-based access mechanism, add the -noauth option to the Xsun command by editing the following line in the /usr/dt/config/Xservers file.

:0  Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner -noauth

By using the -noauth option, you weaken security. It is equivalent to running Solaris software with the host-based access control mechanism only. The server inactivates the user-based access control mechanism. Anyone who can run applications on your local machine is allowed access to your server.

Manipulating Access to the Server

Unless the -noauth option is used with Xsun (see Changing the Default Authorization Protocol), both the user-based access control mechanism and the host-based access control mechanism are active. The server first checks the user-based mechanism, then the host-based mechanism. The default security configuration uses MIT-MAGIC-COOKIE-1 as the user-based mechanism, and an empty list for the host-based mechanism. Because the host-based list is empty, only the user-based mechanism is effectively active. Using the -noauth option instructs the server to inactivate the user-based access control mechanism, and initializes the host-based list by adding the local host.

You can use either of two programs to change a server's access control mechanism: xhost and xauth. For more information, see these man pages. These programs access two binary files that are created by the authorization protocol. These files contain session-specific authorization data. One file is for server internal use only. The other file is located in the user's $HOME directory:

• .Xauthority

• Client Authority file

Use the xhost program to change the host-based access list in the server. You can add hosts to, or delete hosts from the access list. If you are starting with the default configuration—an empty host-based access list—and use xhost to add a machine name, you lower the level of security. The server allows access to the host you added, as well as to any user who specifies the default authorization protocol. See Host-Based Access or an explanation of why the host-based access control mechanism is considered a lower level of security.

The xauth program accesses the authorization protocol data in the .Xauthority client file. You can extract this data from your .Xauthority file so that other users can merge the data into their .Xauthority files, thus allowing them access to your server, or to the server to which you connect.

See Allowing Access When Using MIT-MAGIC-COOKIE-1 for examples of how to use xhost and xauth.

Client Authority File

The client authority file is .Xauthority. It contains entries of the form:

connection-protocol          auth-protocol          auth-data

By default, .Xauthority contains MIT-MAGIC-COOKIE-1 as the auth-protocol, and entries for the local display only as the connection-protocol and auth-data. For example, on host anyhost, the .Xauthority file might contain the following entries:

anyhost:0      MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75
localhost:0    MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75
anyhost/unix:0 MIT-MAGIC-COOKIE-1   82744f2c4850b03fce7ae47176e75  

When the client starts, an entry corresponding to the connection-protocol is read from .Xauthority, and the auth-protocol and auth-data are sent to the server as part of the connection packet. In the default configuration, xhost returns empty host-based access lists and states that authorization is enabled.

If you have changed the authorization protocol from the default to SUN-DES-1, the entries in .Xauthority contain SUN-DES-1 as the auth-protocol and the netname of the user as auth-data. The netname is in the following form:

unix.userid@NISdomainname

For example, on host anyhost the .Xauthority file might contain the following entries, where unix.15339@EBB.Sun.COM is the machine-independent netname of the user:

anyhost:0        SUN-DES-1            ”unix.15339@EBB.Sun.COM”
localhost:0      SUN-DES-1            ”unix.15339@EBB.Sun.COM”
anyhost/unix:0   SUN-DES-1            ”unix.15339@EBB.Sun.COM”

If you do not know your network name, or machine-independent netname, ask your system administrator.

Allowing Access When Using MIT-MAGIC-COOKIE-1

If you are using the MIT-MAGIC-COOKIE-1 authorization protocol, follow these steps to allow another user access to your server:

1. On the machine that is running the server, use xauth to extract an entry that corresponds to hostname:0 into a file.

   For this example, hostname is anyhost and the file is xauth.info:

   myhost% /usr/openwin/bin/xauth nextract - anyhost:0 > $HOME/xauth.info

2. Send the file that contains the entry to the user who requests access,

   Use an email tool, the rcp command, or some other file transfer method to send the file.

   ---

   Note –

   Mailing the file that contains your authorization information is a safer method than using rcp. If you do use rcp, do not place the file in a directory that is easily accessible by another user.

   ---

3. The other user must merge the entry into his or her.Xauthority file.

   For this example, userhost merges xauth.info into the other user's .Xauthority file:

   userhost% /usr/openwin/bin/xauth nmerge - < xauth.info

   ---

   Note –

   The auth-data is session-specific. Therefore, it is valid only as long as the server is not restarted.

   ---

Allowing Access When Using SUN-DES-1

If you are using the SUN-DES-1 authorization protocol, follow these steps to allow another user access to your server.

1. On the machine that runs the server, use xhost to make the new user known to the server.

   For this example, to allow new user somebody to run on myhost:

   myhost% xhost + somebody@

2. The new user must use the xauth command to add the entry into his or her .Xauthority file.

   For this example, the new user's machine independent netname is unix.15339@EBB.Sun.COM. Note that this command should be typed on one line with no carriage return. After the pipe symbol, type a space followed by the remainder of the command.

   userhost% echo 'add myhost:0 SUN-DES-1 “unix.15339@EBB.Sun.COM”' | $OPENWINHOME/bin/xauth

Running Clients Remotely, or Locally as Another User

X clients use the value of the DISPLAY environment variable to get the name of the server to which they should connect.

To run clients remotely, or locally as another user, follow these steps:

1. On the machine that runs the server, allow another user access.

   Depending on which authorization protocol you use, follow the steps outlined in either Allowing Access When Using MIT-MAGIC-COOKIE-1 or Allowing Access When Using SUN-DES-1.

2. Set DISPLAY to the name of the host that runs the server.

   For this example, the host is remotehost:

   myhost% setenv DISPLAY remotehost:0

3. Run the client program as shown.

   myhost% client_program&

   The client is displayed on the remote machine, remotehost.