UNIX: The Complete Reference (2007)

Part II: User Networking

Chapter 9: Networking with TCP/IP

Overview

Many applications require individuals to access resources on remote machines. To meet this need, more and more computers are linked together via various types of communications facilities into many different types of networks. Nowadays, a large percentage of computers have connections to the Internet, a vast network of computers (discussed in Chapter 10).

This chapter will concentrate on the commands built into UNIX for TCP/IP networking. The Internet is based on TCP/IP networking and was originally built using UNIX to link computers running UNIX. The corresponding network administration capabilities devoted to installing, configuring, and maintaining TCP/IP networking are covered in Chapter 17.

UNIX includes networking capabilities that can be used to provide a variety of services over a high-speed network. Using these capabilities, you can carry out such network-based tasks as remote file transfer, execution of a command on a remote host, and remote login. Because these capabilities are available on computers running different operating systems, including all UNIX variants and Windows, TCP/IP networking can be used in heterogeneous environments. Networking based on TCP/IP is the basis for the Internet, which links together computers running many operating systems into one gigantic network. This chapter describes how to use the basic commands in UNIX to carry out networking tasks.

If your computer is not part of a network that is directly connected to the Internet, you can connect your computer to the Internet using a regular telephone connection or a DSL connection. This chapter describes PPP and PPPoE, methods for connecting to the Internet over a telephone line and DSL, respectively. The chapter concludes with a brief discussion of tools available for developing networking applications.

Traditionally, basic communications capabilities in UNIX, such as file transfer and remote execution, were provided by the UUCP system. UUCP communications are based on point-to-point connections, are relatively slow and unsophisticated, and are not supported by many operating systems. This makes them inadequate for supporting high-speed networking and distributed computing If your system still uses the UUCP System, you can consult the companion web site http://books.mcgraw-hill.com/getbook.php?isbn=0072263369&template=computing, for more information.

Basic Networking Concepts

A network is a configuration of computers that exchange information, such as a local area network (LAN), a wide area network (WAN), or the Internet. Computers in a network may be quite different. They may come from a variety of manufacturers and, more likely than not, have major differences in their hardware and software. To enable different types of computers to communicate, a set of formal rules for interaction is needed. These formal rules are called protocols. Different protocol families for data networking have been devel-oped for UNIX systems. The most widely used of these is the Internet Protocol Suite, commonly known as TCP/IP. This protocol suite has been used as the basis for the Internet, a vast worldwide network connecting computers of many different types (the Internet is discussed in Chapter 10).

The Internet Protocol Family

The most widely used set of communications protocols in the UNIX world is the Internet Protocol family, commonly known as TCP/IP. The name TCP/IP comes from two of the important protocols in the family, the Transmission Control Protocol (TCP) and the Internet Protocol (IP). Altogether, more than 100 different protocols are defined in this suite of protocols. The Internet Protocol family can be used to link together computers of many different types, including PCs, workstations, minicomputers, and mainframes, running different operating systems, over local area networks and wide area networks.

TCP/IP was developed and first demonstrated in 1972 by the United States Department of Defense (DoD) to run on the ARPANET, a DoD wide area network. Today the ARPANET is part of the Internet, another WAN, which connects millions of computers all over the world. The term “Internet” is commonly used to refer to both the network and the protocol suite.

How TCP/IP Works

A TCP/IP network transfers data by assembling blocks of data into packets. Each packet begins with a header containing control information, such as the address of the destination, followed by data. When a file is sent over a TCP/IP network, its contents are sent using a series of different packets. The Internet Protocol (IP) permits applications to run transparently over interconnected networks. When IP is used, applications do not need to know about the hardware being used for the networking. Hence, the same application can run over a local area network (such as Ethernet).

The Transmission Control Protocol (TCP), a transport layer protocol, ensures that data is delivered, that what is received was what was sent, and that packets are received in the order transmitted. TCP will terminate a connection if an error makes reliable transmission impossible.

The User Datagram Protocol (UDP), another transport layer protocol used in the Internet, does not guarantee that packets arrive at their destination. It, therefore, can be used over unreliable communications links because an incomplete packet can be received and the missing portions sent again.

The Internet Protocol Suite also specifies a set of application services, including protocols for electronic mail, file transfer, and terminal emulation. These application service protocols serve as the basis for UNIX commands that carry out a variety of networking tasks.

UNIX Commands for TCP/IP Networking

One of the major networking capabilities in UNIX comprises the basic commands for TCP/IP networking. These commands are used to establish TCP/IP connections and provide a set of user-level commands for networking tasks. Most versions of UNIX include two sets of commands used to supply networking services over the Internet, the Berkeley Remote Commands, which were developed at the University of California, Berkeley, and the DARPA Commands.

The DARPA Commands include facilities, independent of the operating system, for such tasks as terminal emulation, file transfer, mail, and obtaining information on users. You can use these commands for networking with computers running operating systems other than UNIX.

The Berkeley Remote Commands include UNIX computer-to-UNIX computer commands for remote copying of files, remote login, remote shell execution, and obtaining information on remote systems and users.

Different versions of UNIX also provide additional networking capabilities. In particular, distributed file systems, such as the Network File System (NFS), are an important networking capability of UNIX. Chapter 15 discusses the networking capabilities provided by distributed file systems.

The next section describes how to use the user-level UNIX TCP/IP commands: the Berkeley Remote Commands and the DARPA Commands.

In this chapter, it is assumed that TCP/IP commands have been installed and configured on your system and that your system is part of a TCP/IP network. (Also see Chapter 17 for information on operation, administration, and maintenance of your TCP/IP network.)

The Remote Commands

UNIX incorporates the Berkeley Remote Commands, which were originally developed as part of the BSD System. These are commonly known as the r* commands, because their names start with r, so that r*matches all their names when the * is considered to be a shell metacharacter.

You can use the Remote Commands to carry out many different tasks on remote machines linked to your machine via a TCP/IP network. The most commonly used of these commands are rcp (remote copy), used to transfer files; rsh (remote shell), used to execute a command on a remote host; and rlogin (remote login), used to log in to a remote host.

The Remote Commands let you use resources on other machines. This allows you to treat a network of computers as if it were a single machine.

Security Features and Issues for the Berkeley Remote Commands

When remote users are allowed to access a system, unauthorized users may gain access to restricted resources. Which remote users have access to a system can be controlled in several ways.

Security for the Remote Commands is managed on both the user level and the host level. On the user level, the system administrator of a remote machine can grant you access by adding an entry for you in the system’s password files. Also, the system administrator on the remote machine may create a home directory on that machine for you.

Unfortunately, the Berkeley Remote Commands are inherently insecure. We will point out some of their security vulnerabilities in our discussion. The numerous security problems with the Berkeley Remote Commands led to the development of a much more secure system called the Secure Shell, discussed later in this chapter. You probably will want to use the Secure Shell rather than the Berkeley Remote Commands if you have security concerns. However, even if you plan to use the Secure Shell, it is worthwhile understanding how the Berkeley Remote Commands work.

Host-Level Security On the host level, each host on a TCP/IP network contains a file called /etc/host.equiv. This file includes a list of the machines that are trusted by that host. Users on remote machines listed in this file can remotely log in without supplying a password.

For instance, if your host, michigan, trusts the remote machines jersey, nevada, and massachusetts, the /etc/host.equiv file on michigan looks like this:

$ cat /etc/host.equiv

jersey

nevada

massachusetts

If the /etc/host.equiv file contains a line with just a plus sign (+), this machine trusts all remote hosts. Misuse of the /etc/host.equiv file may let any remote user log in without a password. Consequently, many system administrators prohibit its use anywhere within the network of an organization or company

User-Level Security Another facility is used to enforce security on the user level. A user who has a home directory on a remote machine may have a file called .rhosts in his or her home directory on that machine. This file is used to allow or deny access to this user’s login, depending on which machine and which user is trying to gain access. The .rhosts file defines “equivalent” users, who are given the same access privileges.

An entry in .rhosts is either a host name, indicating that this user is trusted when accessing the system from the specified host, or a host name followed by a login name, indicating that the login name listed is trusted when accessing the system for the specified host. For instance, if khr has the following .rhosts file in /home/khr on the local system,

$ cat .rhosts

jersey

nevada

massachusetts rrr

massachusetts jmf

delaware

delaware rrr

then the only trusted users are khr, when logging in from jersey, nevada, or delaware; rrr, when logging in from massachusetts or delaware; and jmf, when logging in from massachusetts.

When security is loose on a system, .rhosts files are owned by remote users, to facilitate access. However, when security is tight, root (on the local machine) will be the owner of all .rhosts files and will deny write permission by remote users. Misuse of .rhosts files may allow let unauthorized users access, so system administrators may prohibit their use.

Remote Login

At times you may need to log in to another UNIX computer on a TCP/IP network and carry out some tasks. This can be done using the rlogin command. You can use this command to log in to a remote machine and use it as if you were a local user. This is the general form of this command:

$ rlogin machine

For instance, to log in to the remote machine jersey, use the following command:

$ rlogin jersey

Password: u2a33t {not displayed}

Sun Microsystems Inc. SunOS 5.9 Generic May 2002

jersey

Last login: Sun May 22 16:29:13 from 192.11.105.32

$

In this case, the remote host jersey prompted the user for a password. The remote user correctly entered the password and was logged in to jersey The remote host jersey also supplied the last login time for this user, and the place from which the user last logged in. (In this example, this is specified by the Internet address of a machine on the TCP/IP network, 192.11.105.32. See Chapter 17 for a discussion of this type of address.)

The rlogin command supplies the remote machine with your user ID. It also tells the remote machine what kind of terminal you are using by sending the value of your TERM variable. During an rlogin session, characters are passed back and forth between the two systems because during the session you remain connected to your original host.

You can also use rlogin to log in to a remote system using a different user ID. To do this, you use the -l option followed by the user ID. For instance, to log in to jersey with user ID ams, use this command:

$ rlogin -l ams jersey

Unfortunately, when rlogin is used, all information sent over the connection, including passwords, is transmitted with no encryption, making it vulnerable to interception by unauthorized parties.

Later in this chapter, you’ll learn about another command, telnet, which you can use for logging in to a remote system on your TCP/IP network. Unlike using rlogin, you can use telnet to log in to machines running operating systems other than UNIX. However, when you use telnet to log in to a UNIX computer, telnet does not pass information about your environment to the remote machine, whereas rlogin does this.

rlogin Access Under some circumstances, you can use rlogin to log in to a remote machine without even entering your password on that machine. At other times you will have to supply a password. Finally, under some circumstances you will not be able to log in at all. You are denied access when you attempt to log in to a remote machine if there is no entry for you in the password database on that machine.

If you do have an entry in the password database, and if the name of your machine is in the /etc/hosts.equiv file on the remote machine, you are logged in to the remote machine without entering a password. This happens because the remote machine trusts your machine.

You are also logged in without entering a password if the name of your local machine is not in the /etc/hosts.equiv database, but a line in .rhosts in the home directory of the login on the remote machine contains either your local machine’s name, if the login name is the same as yours, or your local machine’s name and your user name.

Otherwise, when you do have an entry in the password database of the remote machine, but the name of your machine is not in the /etc/hosts.equiv file on the remote host and there is no appropriate line in the .rhosts file in the home directory of the login on the remote machine, the remote machine prompts you for a password. If you enter the correct password for your account on the remote machine, you are logged in to this remote machine. However, even though you can log in, you will not be able to run remote processes such as rsh or rcp. This prevents you from using a multihop login to a secure machine.

When you use rlogin to attempt to log in to a machine not known by your machine, that is, whose host name cannot be resolved, your system will search without success through its host database and then return a message that the remote host is unknown. For instance, suppose you attempt to log in to the remote host nevada from your machine, but this machine is not in the host database of your machine. Your machine will return with the message

$ rlogin nevada

nevada: unknown host

Logging In to a Succession of Machines You can successively log in to a series of different machines using rlogin commands. For instance, starting at your local machine you can log in to jersey using this command:

$ rlogin jersey

Once you are successfully logged in to jersey, you can log in to nevada by issuing the command

$ rlogin nevada

from your shell on jersey This would log you in to all three systems simultaneously

Aborting and Suspending rlogin Connections To abort an rlogin connection, simply enter CTRL-D, exit, or ~. (tilde dot). You will return to your original machine. Note that when you have logged in to a succession of machines using rlogin, typing ~. returns you to your local machine, severing all intermediate connections. To abort only the last connection, type ~ ~. (tilde tilde dot).

If you are using a job control shell, such as jsh, you can suspend an rlogin connection, retaining the ability to return to it later. To do this, type ~ CTRL-Z (tilde CTRL-Z). When you suspend an rlogin connection, this connection becomes a stopped process on your local machine and you return to the original machine from which you issued the rlogin command. You can reactivate the connection by typing fg followed by a RETURN, or % followed by the job number of the stopped process.

When you are logged in to a succession of machines using rlogin, typing ~ CTRL-Z returns you to your local machine. Typing ~ ~ CTRL-Z (tilde tilde CTRL-Z) suspends only your last rlogin connection.

You can change the ~ to another character (here noted as c) by using the ~e option followed by the character you want to be the abort sequence, as shown in the following format:

$ rlogin ~ec remote_host_name

For instance, the command

$ rlogin ~e+ jersey

begins the remote login process to jersey and sets the abort sequence to +. (plus dot).

Copying Files Using rcp

Suppose that you want to send a letter to everyone on a mailing list, but the file containing the names and addresses is located on a remote machine. You can use the rcp command to obtain a copy of this list. The rcp command is used to copy files to and from remote machines on a TCP/IP network.

This is the general form of an rcp command line:

$ rcp source_machine:file destination_machine:file

To use rcp to transfer files to or from a remote machine, you must have an entry in the password database on that machine, and the machine you are using must be in the remote machine’s list of trusted hosts (either in the /etc/host.equiv file or in your .rhosts file on the remote machine).

Copying from a Remote Host To be able to copy a file from a remote machine, you must have read permission on this file. To use rcp to copy a file into a specified directory, giving the file the same name it has on the remote system, use a command line of the form

$ rcp host:pathname directory

For instance, to copy the file named /home/phonelist on the remote machine jersey into your directory /home/data on your local machine, naming the file /home/data/phonelist, use the command

$ rcp jersey:/home/phonelist /home/data

You can also change the name of the file when you copy it by specifying a filename. This is the general form of this use of the rcp command:

$ rcp host:pathname directory/file

For instance, the command

$ rcp jersey:/home/phonelist /home/data/numbers

copies the file /home/phonelist on jersey into the file /home/data/numbers on your local machine.

When you copy files using rcp, you can use whatever abbreviations for directories are allowed by the shell you are using. For instance, with the standard shell, the command line

$ rcp jersey:/home/phonelist $HOME/numbers

copies the file /home/phonelist on jersey to the file numbers in your home directory on your local machine.

Copying from Your Machine to a Remote Machine You can also use rcp to copy a file from your machine to a remote machine. You must have write permission on the directory on the remote machine that you want to copy the file to.

This is the general form of the rcp command used to copy a file from your machine to a remote machine:

$ rcp file host:directory

For instance, to copy the file /home/numbers on your machine into the directory /home/ data on the remote host jersey, naming it /home/data/numbers, use this command:

$ rcp /home/numbers jersey:/home/data

To rename the file on the remote machine, use a command line of the following form:

$ rcp file host:directory/file

For instance, the command

$ rcp /home/numbers jersey:/home/data/lists

renames the copied file /home/data/lists.

Using rcp to Copy Directories You can copy entire directory subtrees using the rcp command with the -r option. This is the general form of the command line used to copy a remote directory into a specified directory on your machine:

$ rcp -r machine:directory directory

For instance, you can copy the directory /home/data on the remote machine jersey into the directory /home/info on the local machine using this command:

$ rcp -r jersey:/home/data /home/info

To copy a local directory into a specified directory on a remote host, you use a command line of the form

$ rcp -r directory machine:directory

Thus, to copy the directory /home/info on the local machine into the directory /home/data on the remote machine jersey, use the command line

$ rcp -r /home/info jersey:/home/data

Using Shell Metacharacters with rcp Be careful when you use shell metacharacters with rcp commands. Shell metacharacters are interpreted on the local machine instead of on the remote machine unless you use escape characters or quotation marks. For example, suppose you want to copy the files /etc/f1 and /etc/f2 on the remote machine jersey, and that in your current directory on the local machine you have files named friends and fiends. To attempt to copy the files /etc/f1 and /etc/f2 on jersey into your current directory, you type this:

$ rcp jersey:/etc/f*

Your local shell expands f* to match the filenames friends and fiends. Then it attempts to copy the files /etc/friends and /etc/fiends on jersey, which was not what you intended.

You can avoid this problem using an escape character like this:

$ rcp jersey:/etc/f\*

You can also use this:

$ rcp \'jersey:/etc/f*\'

Creating a Remote Shell with rsh

Sometimes you may want to execute a command on a remote machine without logging in to that machine. You can do this using the rsh (for remote shell) command (HP-UX users should note that this command is called remsh in HP-UX systems). An rsh command executes a single command on a remote UNIX system host on a TCP/IP network. (Do not confuse the remote shell rsh with the restricted shell, discussed in Chapter 12. Although the restricted shell also has the name rsh, it is not a user-level command. Chapter 12 describes how the restricted shell is run.)

To use rsh, you must have an entry in the password database on the remote machine, and the machine you are using must be a trusted machine on this remote host, either by being listed in the /etc/hosts.equivfile or by having an appropriate entry in your .rhosts file in your home directory on the remote machine.

This is the general form of an rsh command:

$ rsh host command

For instance, to produce a complete listing of the files in the directory /home/khr on jersey, use this command:

$ rsh jersey ls -l /home/khr

The output of the ls -l command on jersey is your standard output on your local machine.

The command rsh does not actually log in to the remote machine. Rather, a daemon on the remote machine generates a shell for you and then executes the command that you specify The type of shell generated is determined by your entry in the password database on the remote host. Also, the appropriate startup file for your shell (i.e., your .profile on the remote host if you use the standard shell) is invoked.

Shell Metacharacters and Redirection with rsh

Shell metacharacters and redirection symbols in an rsh command that are not quoted or escaped are expanded at the local level, not on the remote machine. For instance, the command

$ rsh jersey ls /usr/bin > /home/khr/list

lists files in the directory /usr/bin on the machine jersey, redirecting the output to the file /home/khr/list on the local machine. This is the outcome because the redirection symbol > is interpreted at the local level.

To perform the redirection on the remote machine and place the list of files in /usr/bin on jersey into the file /home/khr/list on jersey, use single quotes around the redirection sign >:

$ rsh jersey ls /usr/bin '>' /home/khr/list

Using a Symbolic Link for rsh Commands

When you find that you often issue rsh commands on a particular machine, you can set up a symbolic link that lets you issue an rsh command on that host simply by using the name of that host. For instance, suppose you run the command

$ ln -s /usr/sbin/rsh /usr/hosts/jersey

and put the directory /usr/hosts in your search path. Instead of using the command line

$ rsh jersey ls /usr/bin

you can use the simpler command line

$ jersey ls /usr/bin

When you make this symbolic link, you can also remotely log in to jersey by simply issuing the command

$ jersey

which is shorthand for this:

$ rlogin jersey

Using rwall

Another r* command that you might find useful is rwall (from remote write all), available on many versions of UNIX. This command is used to send a message to all users on a remote host (as long as this host is running the rwall daemon, rwalld). (Note that this capability is often restricted to just root by system administrators.) For instance, you can send a message to all users on the remote machine saginaw using the following command:

$ rwall saginaw

Please send your monthly activity report to

Yvonne at california!ygm by Friday. Thanks!

CTRL+D

You end your message by typing CTRL-D to signify end-of-file. This message will be delivered to all users on saginaw, beginning with the line that looks like this:

Broadcast message from ygm on california ...

The DARPA Commands, Including ftp and telnet

Unlike the r* commands, the DARPA commands can be used for networking between UNIX computers and machines running other operating systems.

Using ftp

Copying files to and from remote machines is one of the most common networking tasks. As you have seen, you can use rcp to copy files to and from a remote machine when this machine is also running a version of the UNIX System that includes rcp and you have a login on the remote machine or the machines trust each other. However, you may want to copy files on machines running other operating systems, or variants of the UNIX System that do not support rcp. This can be done using the ftp command (as long as the remote machine supports the ftp daemon ftpd). You also can use ftp to copy files when you do not know the names of the files.

The ftp command implements the File Transfer Protocol (FTP), permitting you to carry on sessions with remote machines. When you issue an ftp command, you begin an interactive session with the ftpprogram, like this:

$ ftp

ftp>

You can display a list of available ftp commands by entering a question mark, ?, or typing help at the ftp prompt. You can get information on a command using the help command. For instance, you can get information on the open command using this ftp command line:

ftp> help open

To run an ftp command, you only need to supply ftp with as many letters of the command name as are needed to uniquely identify the command. If you do not supply enough letters to uniquely identify the command, ftp tells you,

f tp>n

?Ambiguous command

ftp>

Opening an ftp Session

To begin a session with a remote host, you use the ftp open command. The following is an example of the beginning of an ftp session with the remote host jersey:

ftp> open

(to) jersey

Connected to jersey

220 jersey FTP server (Version 1.1 May 16 2006) ready.

Name (jersey:khr): khr

331 password required for khr.

Password: a2ux4 {this is not displayed}

230 user khr logged in.

The first line shows that the ftp command open was issued. Then, ftp came back with the prompt "(to)" and the name of the remote machine, jersey, was supplied as input. The third and fourth lines are the response from the FTP server on the remote machine. The fifth line is the prompt for the login name on the remote machine. The sixth line is the statement from the FTP server that the user khr needs to supply a password. Then the password prompt is given. After the correct password has been supplied (which is not echoed back), the FTP server gives the message that khr is logged in.

You can also specify a remote host when you issue your ftp command line. For instance, to begin an ftp session with the remote host jersey, enter the command

$ ftp jersey

Using ftp Commands

Once you have opened an ftp session with a remote host, you can use the many different ftp commands to perform a variety of tasks on the remote host. For instance, you can list all the files accessible to you on the remote host by issuing an ftp ls command. You can also change directories using an ftp cd command, but you will not be able to access files in this directory unless you have permission to do so. When you use ftp commands, you are not running commands on the remote machine directly; instead, you are giving instructions to the ftp daemon on the remote machine.

You can escape to the shell and run a shell command on your local machine using an exclamation mark followed by the command. For instance, you can run the date command with this ftp command line:

ftp> ! date

Copying Files Using ftp

To copy a file once you have established your ftp connection, use the get and put commands. Before copying a file, you should make sure the correct file transfer type is set. The default file transfer type is ASCII (although on some systems the system administrator will set up a binary default). To set the file transfer type to binary, use this command:

ftp> binary

To set the file transfer type back to ASCII, use this command:

ftp > ascii

Once the file transfer type is set, you can use the get and put commands. For instance, to copy the file lists from the remote host jersey, with which you have established an ftp session to your machine, use the get command of ftp, as the following session shows:

ftp> get lists

200 PORT command successful.

150 ASCII data connection for names (192.11.105.32, 1550) (35 bytes).

226 ASCII Transfer complete.

local: lists remote: lists

43 bytes received in 0.02 seconds (2.1 Kbytes/s)

To copy the file numbers from your machine to jersey, use the put command of ftp, as the following session shows:

ftp> put numbers

200 PORT command successful.

150 ASCII data connection for numbers (192.11.105.32, 1552).

226 Transfer complete.

local: numbers remote: numbers

6355 bytes sent in 0.22 seconds (28 Kbytes/s)

When you use either the get or put command, ftp reports that the transfer has begun. It also reports when completion occurs and tells you how long the transfer took.

You can copy more than one file using the mget and mput commands, together with the appropriate metacharacters. (These metacharacters are interpreted by ftp as you would expect; there are no problems with having local shells interpret metacharacters as with r* commands because ftp is an application program rather than a shell.) When you use either of these commands, ftp asks interactively whether you wish to transfer each file. You enter y if you want to transfer the file and n if you do not want to transfer the file. After going through all files, you get an ftp prompt.

For example, to copy the remote files t1 and t2, but not t3, you can use the following session:

ftp> mget

(remote-files) t*

mget t1? y

200 PORT command successful.

150 ASCII data connection for t1 (192.11.105.32, 2214) (180 bytes).

226 ASCII Transfer complete.

local: t1 remote: t1

190 bytes received in 0.02 seconds (9.3 Kbytes/s)

mget t2? y

200 PORT command successful.

150 ASCII data connection for t2 (192.11.105.32, 2216) (1258 bytes).

226 ASCII Transfer complete.

local: t2 remote: t2

1277 bytes received in 0.04 seconds (31 Kbytes/s)

mget t3? n

ftp>

Similarly, to copy the files names and numbers, but not lists (if these are all the files in the current directory on the local machine) to the remote machine, you can use this session:

ftp> mput

(local-files) *

mput lists? n

mput names? y

200 PORT command successful.

150 ASCII data connection for names (192.11.105.32, 2220).

226 Transfer complete.

local: names remote: names

mput numbers? y

200 PORT command successful.

150 ASCII data connection for numbers (192.11.105.32,2222).

226 Transfer complete.

local: numbers remote: numbers

43 bytes sent in 0.11 seconds (0.38 Kbytes/s).

ftp>

Terminating and Aborting ftp Sessions

To terminate an ftp session, type quit at the ftp prompt:

ftp> quit

221 Goodbye.

If the remote machine or the communications link goes down, you can use the BREAK key (interrupt) to abort the ftp session and return to your shell on the local machine.

Retrieving Files via Anonymous FTP

A tremendous variety of public domain software is available on the Internet. The most common way that these programs are distributed is via anonymous FTP, a use of ftp where users do not need a login on the remote machine. You can find sources for many public domain programs that you can obtain using anonymous FTP by reading netnews or by consulting various web sites.

It would be infeasible to add an entry to the password database of a machine whenever a remote user on the Internet logs in. To avoid this problem, administrators can configure their systems so that remote users can use ftp to log in, for the purpose of copying a file, with a particular string such as “anonymous” or “ftp”; a valid e-mail address or any string is accepted as a valid password. Usually systems ask users to supply “ident” or “guest” as their password; the system expects the remote user to enter a name or electronic address as the password.

The following example illustrates an anonymous FTP session:

$ ftp jersey.att.com

Connected to jersey.att.com

220 jersey.ATT.COM FTP server ready.

Name (jersey.att.com: khr): anonymous

331 Guest login ok, send ident as password.

Password: khr@orono. maine.edu {not displayed}

230 Guest login ok, access restrictions apply.

ftp> cd /pub/math

250 CWD command successful.

ftp> get primetest

200 PORT command successful.

150 ASCII data connection for primetest (192.11.105.32, 2229) (17180 bytes).

226 Transfer complete

local: primetest remote: primetest

17180 bytes received in 19 seconds (0.90 Kbytes/s)

ftp> quit

221 Goodbye

Large files and software packages are often made available in compressed tar format, which have a .tar.Z extension. To use ftp to transfer such files, you must first use the ftp binary command. When you receive the file from the remote system, first use uncompress and then tar to recover the original file.

Chapter 17 explains how you can enable your system to share files via anonymous FTP.

The use of ftp for anonymous file transfer on the Internet is far and away the predominant use of ftp. There is a reservoir of archive sites that hold thousands of files. Table 9–1 displays a list of some commonly used ftp commands and their actions.

Invoking ftp via a Web Browser

You do not need to use the traditional command-line interface for ftp if you have a web browser such as Firefox or Mozilla installed on your system. When you have a web browser, you can access an anonymous FTP site by using a URL of the form ftp://ftp.foobar.com (where ftp://ftp.foobar.com is the anonymous FTP site you wish to access). See Chapter 10 for details.

Using tftp

Another command is available that can be used for file transfer to and from remote hosts. The tftp command, which implements the Trivial File Transfer Protocol (TFTP), uses the User Datagram Protocol (UDP) instead of the Transmission Control Protocol (TCP) used by ftp. You can use tftp when you have no login on the remote machine. Because there is no validation of users with tftp, it can only be used to transfer files that are publicly readable. Because tftp does not authenticate users, it is extremely insecure. This means that it is often unavailable on server machines.

Unlike ftp, when you use tftp you are not running an interactive session with a remote host. Instead, your system communicates with the remote system whenever it has to.

You begin a tftp session by issuing this tftp command:

$ tftp

tftp>

Once the tftp session has been started, you can issue a tftp command. You can display a list of tftp commands by entering a question mark (?) at the tftp prompt:

tftp> ?

Commands may be abbreviated. Commands are:

connect connect to remote tftp

mode set file transfer mode

put send file

get receive file

quit exit tftp

verbose toggle verbose mode

trace toggle packet tracing

status show current status

binary set mode to octet

ascii set mode to netascii

rexmt set per-packet retransmission timeout

timeout set total retransmission timeout

? print help information

For instance, to connect to a remote host for copying files, you use this tftp connect command:

$ tftp

tftp> connect

(to) jersey

After you enter the tftp command connect, tftp gives you the prompt “(to).” You enter the system name jersey Then tftp establishes a connection to the machine jersey (if it can).

You can also establish a tftp session by supplying the name of the system on your command line, like this:

$ tftp jersey

You can use the tftp status command to determine the current status of your tftp connection:

tftp> status

connected to jersey

mode: netascii verbose: off tracking: off

remxt-interval: 5 seconds max-timeout: 25 seconds

Remote Login Using telnet

You can use rlogin to log in to a remote UNIX computer. However, you may want to log in to a system running some other operating system, or a different version of the UNIX System. This can be accomplished using the telnet command.

To begin a telnet session, you run the telnet command, like this:

$ telnet

telnet>

Once you have established a telnet session, you can run other telnet commands. You can display a list of these commands by entering the telnet command help or a question mark:

telnet> help

Commands may be abbreviated. Commands are:

close Close current connection

display display operating parameters

mode try to enter line-by-line or character-at-a-time mode

open connect to a site

quit exit telnet

send transmit special characters ('send ?' for more)

set set operating parameters ( 'set ?' for more)

status print status information

toggle toggle operating parameters ('toggle ?' for more)

z suspend telnet

? print help information

You can use the telnet open command to establish a telnet session with a remote host. For instance, you would use this command line to start a session with the remote machine michigan:

telnet> open michigan

You can also establish a telnet session with a remote host by supplying the machine name as an argument to the telnet command. For instance, you can start a session with michigan by typing this:

$ telnet michigan

This is the response:

Trying ...

Connected to michigan

Escape character is '^]'

It is followed by the ordinary login sequence on the machine michigan. Of course, you must have credentials to log in to michigan. Also note that telnet tells you the escape character it recognizes, which in this case is CTRL-].

If you try to use telnet to log in to a machine that is not part of your network, telnet searches through the host database on your machine. Then it tells you that the machine you are trying to log in to is not part of the network. After receiving this message, you receive another telnet prompt. If you wish, you can terminate your telnet session by typing quit, or simply q.

Aborting and Suspending telnet Connections

You can abort a telnet connection by entering the telnet escape character, which usually is CTRL-], followed by quit. This returns you to your local machine. When you abort a connection to a machine you reached with a series of telnet commands, you return to your original machine.

You can suspend a telnet connection by typing CTRL-Z. When you do this, the telnet process becomes a background process. To reactivate a suspended telnet session, type fg.

Invoking telnet via a Web Browser

If a web browser such as Netscape Navigator is installed on your system, you can set up a telnet session by supplying a URL in the form telnet://foobar.com (where foobar.com is the name of the remote system you wish to log in to). See Chapter 10 for details.

Obtaining Information About Users and Hosts

Before using remote commands, you may want to obtain some information about machines and users on the network. You can get such information using any of several commands provided for this purpose, including rwho, which tells you who is logged in to machines on the network; finger, which provides information about specific users on a local or remote host on your network; ruptime, which tells you the status of the machines on the network; and ping, which tells you whether a machine is up or down. You may also want to run traceroute to investigate network issues; this command will tell you the route packets are taking to reach a remote host.

The rwho Command

You can use the rwho command to print information about each user on a machine on your network. The information you get includes the login name, the name of the host, where the user is, and the login time for each user. For instance,

$ rwho

avi peg:console Oct 15 14:53

khr pikes:console Oct 15 17:32

jmf arch:ttya2 Oct 15 12:21

rrr homx:ttya3 Oct 15 17:06

zeke xate:ttya0 Oct 15 17:06

The finger Command

You can obtain information about a particular user on any machine in your network using the finger command. You obtain the same type of information about a user on a remote machine as you would for a user on your own machine (see Chapter 2). To obtain information about a user on a remote host, supply the user’s address. For instance, to obtain information about the user khr on the machine jersey, use this command line:

$ finger khrjersey

On some machines, finger is disabled for remote users for security reasons.

The ruptime Command

You can use the ruptime command to obtain information about the status of all machines on the network. The command prints a table containing the name of the host on the local network, whether the host is up or down, the amount of time it has been up or down, the number of users on that host, and information on the average load on that machine for the past minute, 5 minutes, and 15 minutes. For example,

$ ruptime

aardvark up 21+02 24, 6 users, load 0.09, 0.05, 0.02

bosky up 20+07 58, 5 users, load 1.23, 2.08, 1.87

fickle up 6+18 48, 0 users, load 0.00, 0.00, 0.00

jazzy up 1+02 31, 8 users, load 4.29, 4.07, 3.80

kitsch up 21+02 06, 9 users, load 1.06, 1.03, 1.00

lucky up 21+02 06, 4 users, load 1.09, 1.04, 1.00

olympia up 21+02 05, 0 users, load 1.00, 1.00, 1.00

sick down 2+07 14

xate up 2+06 39, 1 user, load 1.09, 1.20, 1.57

The preceding shows that the machine aardvark has been up for 21 days, 2 hours, and 24 minutes, has 6 current users logged in, had an average load of 0.09 processes in the last minute, 0.05 processes in the last 5 minutes, and 0.02 processes in the last 15 minutes. The machine sick has been down for 2 days, 7 hours, and 14 minutes.

The ping Command

Before using a remote command, you may wish to determine whether the remote machine you wish to contact is up. You can do this with the ping command. Issuing this command with the name of the remote machine as an argument determines whether a remote host is up and connected to the network or whether it is down or disconnected from the network.

For instance, the command

$ ping jersey

jersey is alive

tells you that the remote host jersey is up and connected to your network. If jersey is down or is disconnected from the network, you would get this:

$ ping jersey

no answer from jersey

A remote system may be running and connected to your network, but communication with that system may be slow. You can obtain more information about the connection between your system and the remote system if you are running a variant of UNIX that supports options to the ping command (or that supports the traceroute command-see the next section). For example, you may be able to monitor the response time between your system and the remote system (on Solaris, the -s option to ping does this). You may even be able to use the ping command to track the actual route that packets between your system and the remote system take in the Internet (on Solaris the -svlR combination of options does this). Consult the manual page for ping on your particular system for details on how to obtain similar information for Internet connections from your system.

The traceroute Command

The traceroute command is available on most modern UNIX variants. This command can be used to find the route through the Internet packets from your computer taken to reach a remote host. You may want to use this command when you get no response from a remote host when you use the ping command. Running the traceroute command will tell you whether there is a problem with your connection to the Internet or whether packets are just not reaching their ultimate destination. That is, you will be able to see whether there is a broken link that is preventing your packets from the remote host, or whether a particular link is slow.

The information shown in each line of traceroute output includes

§ The hop number. Hop 1 begins at your machine; all hops needed to reach the destination are displayed, if this host can be reached, as long as the number of hops does not exceed a preset limit (which is 30 hops by default, but which can be changed using the -m option to traceroute). If the destination cannot be reached, all hops that make their way to an intermediate machine are shown.

§ The host name at each hop, or the IP address when there is no reverse DNS for this host.

§ The IP address, shown in parentheses.

§ The times used by three separate probes to reach the host at this hop.

For example, here is the output of the traceroute command when run from the machine www.net.berkeley.edu with the machine stanford.edu as the destination.

$ traceroute stanford.edu

1 inr-211-inr-203--128–32–206–1.HSRP.Berkeley.EDU (128.32.206.1) 0.433 ms 0.349 ms 0.306 ms

2 g3–1.inr-201-eva.Berkeley.EDU (128.32.255.1) 0.544 ms 0.389 ms 0.369 ms

3 ge-1–2-0.inr-002-reccev.Berkeley.EDU (128.32.0.36) 49.401 ms 0.445 ms 10.171 ms

4 hpr-oak-hpr-ucb-ge.cenic.net (137.164.27.129) 0.797 ms 0.616 ms 0.760 ms

5 hpr-stan-ge-oak-hpr.cenic.net (137.164.27.158) 1.947 ms 1.943 ms 1.962 ms

6 bbr2-rtr.Stanford.EDU (171.64.1.133) 2.165 ms 2.261 ms 2.261 ms

7 www4.Stanford.EDU (171.67.20.36) 2.248 ms 2.360 ms 2.384 ms

The Secure Shell (ssh)

The Berkeley Remote Commands and the DARPA Commands allow users access to resources on remote computers. Unfortunately, as mentioned earlier in this chapter, systems that enable these commands are vulnerable to attack by unauthorized parties. For example, an intruder with root access to a computer on the network, or who has tapped into the network itself, can obtain passwords of users. Because of these and other security concerns, system administrators on many UNIX systems disable these remote commands.

To solve the security problems of the Berkeley Remote Commands while allowing the same functions they perform to be carried out, in 1995, Tatu Ylönen at the Helsinki University of Technology, Finland, created the Secure Shell (SSH). Although the first few releases of the Secure Shell were freely available, Ylönen decided to develop later versions as propriety software owned by a company he founded, SSH Communications Security In 1999, members of the OpenBSD development team (see Chapter 1) decided to create an open-source free version of the Secure Shell, which they named OpenSSH. The OpenSSH is available for Linux, Solaris, AIX, OpenBSD, HP-UX, Mac OS X, and other UNIX variants. Other commercial versions of the Secure Shell, besides the SSH Secure Shell, and other open-source versions of the Secure Shell, besides OpenSSH are also available.

The Secure Shell, as offered by a commercial vendor or an open-source supplier, is a program that allows users to log in to computers over a network, to copy files from one computer to another, and to execute commands on a remote machine, all in secure ways. The Secure Shell provides security by authenticating users and by providing secure communications over connections that may not be secure. That is, the Secure Shell was designed to carry out the same functions as the Berkeley Remote Commands, without leading to the same security vulnerabilities. The Secure Shell provides security in many ways. For example, when the Secure Shell is used, both ends of the connection are automatically authenticated and all passwords sent over the network are first encrypted. The Secure Shell uses both private- and public-key cryptography for encryption and authentication functions. The particular algorithms employed vary according to whether you are using a free version or a commercial version of the Secure Shell software.

The specific versions of the commands supported by different variants of the Secure Shell vary For example, the OpenSSH suite replaces the rlogin command, as well as the telnet command, with the sshcommand. It replaces rcp with scp, and it replaces ftp with sftp.

For example, suppose you have an account on the remote machine jersey.att.com and are running the OpenSSH suite. To connect to this machine as a remote server, type

$ ssh jersey.att.com

If this is the first time that you are connecting to this remote host via ssh, you will be asked whether you want to continue connecting. If you answer yes, this host will be added to your known_hosts file. (More precisely, the name of this host and its encryption key are added to the known_hosts file.) When you make successive connections to this remote host, you will not be asked whether you want to continue connecting. When you use ssh to connect to a remote host in your known_hosts file, your password is automatically provided to the remote system. If the host key has changed, you will see a warning message when you attempt to connect to this host. Note that when you use ssh, you are assured that you are connecting to the correct host and that you have an encrypted connection with the remote host that cannot be intercepted and decrypted by an intermediate party

If the Secure Shell is not already installed on the system you use, you can obtain it over the Internet. You can download it from http://www.openssh.com/. You can find the manual pages for the Secure Shell commands at http://www.openssh.com/manual.html.

PPP and PPPoE

If your machine is part of a network that is directly connected to the Internet, you can remotely log in to or exchange files with these other machines via telnet and ftp, respectively But what if your computer is not part of such a network? In that case you can set up a TCP/IP connection over a regular telephone line or a DSL line by using a special protocol, PPP in the case of regular telephone lines and PPPoE in the case of DSL lines, that supports Internet access over serial connections. To set up such a connection, you need PPP or PPPoE client software, a telephone and a modem or a DSL line and a DSL modem, and a PPP or PPPoE account with an Internet service provider. PPP and PPPoE software is available for many UNIX variants.

The Point-to-Point Protocol (PPP) was developed as an alternative to an earlier protocol, the Serial Line Internet Protocol (SLIP), without the many problems of SLIP. PPP is based on work done in 1989 by Russ Hobby at the University of California, San Diego, and Drew Perkins at Carnegie Mellon University PPP was adopted as an Internet Standard 51 in 1994 by the Internet Engineering Task Force (IETF), which is responsible for standardization on the Internet. PPP provides for error detection and offers data compression capabilities. PPP and PPPoE software is bundled with or is available with many versions of UNIX.

Summary

This chapter described the networking capabilities provided by TCP/IP commands in UNIX. You saw how the Berkeley Remote Commands can be used for networking between UNIX System computers, including remote login, remote execution, and file transfer. The DARPA Commands, which can be used for networking in heterogeneous TCP/IP environments, were also introduced. The DARPA Commands can be used for remote login and file transfer between computers running different operating systems, as long as they run TCP/IP software. The Secure Shell, designed to eliminate the security problems of the Berkeley Remote Commands, was described. Protocols that can be used to set up TCP/IP connections over a telephone connection, PPP and PPPoE, were also discussed.

The capabilities covered in this chapter are part of the networking and communications facilities in UNIX that include the mail system, the UUCP system (discussed on the companion web site), and distributed file systems (discussed in Chapter 15). Administration, operation, and management of the TCP/IP Internet Package are discussed in Chapter 17.

You will learn more about the Internet and the wide variety of services available on the Internet in Chapter 10.

How to Find Out More

To find out more about UNIX TCP/IP and related concepts, consult these resources:

· Comer, Douglas E., and D. Stevens. Internetworking with TCP/IP, Volumes I, II, and III (various editions). Englewood Cliffs and Upper Saddle River, NJ: Prentice Hall, 1996–2005.

· Petersen, Richard. Linux: The Complete Reference. 5th ed. Berkeley, CA: McGraw-Hill-/ Osborne, 2002.

· Petersen, Richard. UNIX Networking Clearly Explained. Chestnut Hill, MA: AP Professional, 1999.

· Stevens, R. UNIX Network Programming. Volumes I and II (various editions). Englewood Cliffs and Upper Saddle River, NJ: Prentice Hall, 1998–2003.

You can consult some useful web sites for additional information about the Secure Shell. In particular, FAQs on the Secure Shell can be found at http://www.employees.org/~satch/ssh/faq/. An excellent tutorial on the Secure Shell is available at http://www.tac.nyc.ny.us/~kim/ssh/#ss. You can also consult the newsgroup comp.security.ssh.