Basic network access: clients

Finally we have set up the network connections, and everything is working. What can we do with the network? In this part of the book, we'll take a look at some of the more important services that make up the application layer.

The Internet protocols perform most services with a pair of processes: a client at one end of the link that actively asks for services, and a server at the other end of the link that responds to requests and performs the requested activity. These terms are also used to describe computer systems, but here we're talking about processes, not systems. In this chapter, we'll look at the client side of things, and in "Basic network access: servers" , Basic network access: servers we'll look at the corresponding servers.

Probably the single most important network service is the Hypertext Transfer Protocol or HTTP, the service that web browsers use to access the Web. We'll look at web browsers in the next section.

The next most important service is probably the Simple Mail Transfer Protocol or SMTP, the primary service for sending mail round the Internet. There's also the Post Office Protocol or POP, which is used by systems unable to run SMTP. This topic is so important that we'll devote "Electronic mail: clients" and "Electronic mail: servers" to it.

To use a remote machine effectively, you need better access than such specialized servers can give you. The most powerful access is obviously when you can execute a shell on the remote machine; that gives you effectively the same control over the machine as you have over your local machine. A number of services are available to do this. In the olden days, you would use telnet or rlogin to log into another machine. These programs are still with us, but security concerns make them effectively useless outside a trusted local network. We'll look at them briefy on page 430.

The preferred replacement is ssh, which stands for secureshell. In fact, it's not a shell at all, it's a service to communicate with a remote shell. It encrypts the data sent over the network, thus making it more difficult for crackers to abuse. We'll look at it in detail on page 419.

Another important service is the ability to move data from one system to another. There are a number of ways of doing this. The oldest programs are rcp and ftp. These programs have the same security concerns as telnet and rlogin, though ftp still has some uses. More modern copying programs use scp, which is based on ssh. We'll look at file copy programs on page 432. In addition, rsync is a useful program for maintaining identical copies files on different systems. We'll look at it on page 437.

A some what different approach is the Network File System or NFS, which mounts file systems from another machine as if they were local. We look at NFS clients on page 441.

The World Wide Web

For the vast majority of the public, the Internet and the World Wide Web are the same thing. FreeBSD is an important contender in this area. Some of the world's largest web sites, including Yahoo! (http://www.yahoo.com/) run FreeBSD. Even Microsoft runs FreeBSD on its Hotmail service (http://www.hotmail.com/), though they have frequently denied it, and for image reasons they are moving to their own software.

Web browsers

A web browser is a program that retrieves documents from the Web and displays them. The base FreeBSD system does not include a web browser, but a large number are available in the Ports Collection. All web browsers seem to have one thing in common: they are buggy. They frequently crash when presented with web pages designed for Microsoft, and in other cases they don't display the page correctly. In many cases this is due to poorly designed web pages, of course.

Currently, the most important web browsers are:

• netscape was once the only game in town, but it's now showing its age. In addition, many web sites only test their software with Microsoft, and their bugs cause problems with netscape.
• mozilla is derived from the same sources as netscape, but comes in source form. It has now reached the stage where it is less buggy than netscape. A number of other browsers, such as galeon and skipstone, are based on mozilla. They're all available in the Ports Collection. galeon is included in the instant-workstation port described in "Post-installation configuration" .
• konqueror is included with the KDE port.
• Opera is a new browser that some people like. The version in the Ports Collection is free, but it makes up for it by giving you even more advertisements than the web pages give you anyway. You can buy a version that doesn't display the advertisements.
• lynx is a web browser for people who don't use X. It displays text only.

You may note two omissions from this list. Microsoft's Internet Explorer is not available for FreeBSD. Not many people have missed it. Also, mosaic, the original web browser, is now completely obsolete, and it has been removed from the Ports Collection.

In addition to these browsers, StarOffice and OpenOffice include integrated browsers. You may find you prefer them.

This book does not deal with how to use a web browser: just about everybody knows how to use one. You can also get help from just about any browser; just click on the text or icon marked Help or ?.

ssh

ssh is a secure shell, a means of executing programs remotely using encrypted data transfers. There are a number of different implementations of ssh: there are two different protocols, and the implementations are complicated both by bugs and license conditions. FreeBSD comes with an implementation of ssh called OpenSSH, originally developed as part of the OpenBSD project.

Using ssh is simple:

$ ssh freebie
The authenticity of host 'freebie.example.org (223.147.37.1)' can't be established.
DSA key fingerprint is 08:f7:c4:14:48:0b:14:06:0e:2c:93:4b:1f:f6:ce:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'freebie.example.org' (DSA) to the list of known hosts.
grog@freebie.example.org's password:    as usual, doesn't echo
Last login: Mon May 13 14:21:11 2002
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE (FREEBIE) #3: Sun Jan 5 13:25:02 CST 2003

Welcome to FreeBSD!
$ tty
/dev/ttyp3
$

Once you get this far, you are connected to the machine in almost the same manner as if you were directly connected. This is particularly true if you are running X. As the output of the tty command shows, your "terminal" is a pseudo-tty or pty (pronounced "pity"). This is the same interface that you have with an xterm.

It's worth looking in more detail at how the connection is established:

• The first line (The authenticity...) appears once ssh has established preliminary contact with the remote system. It indicates that you're connected, but that the local system has no information about the remote system. Theoretically you could be connected to a different machine masquerading as the machine you want to connect to. ssh saves the fingerprint in ~/.ssh/known_hosts and checks it every time you connect to that machine thereafter.
• The reference to DSA keys indicates that ssh is using the ssh Version 2 protocol. We'll look at the differences between the protocols below.
• The password prompt is for the same password as you would see locally. The slightly different format is to clarify exactly which password you should enter. Again, a number of exploits are possible where you might find yourself giving away a password to an intruder, so this caution is justified.

When you log in via ssh, there's a chance that your TERM environment variable is set incorrectly. See table 7.3 on page 130 for more details. Remember that TERM describes the display at your end of the link. There is no display at the other end, but the other end needs to know the termcap parameters for your display. If you're running an xterm, this shouldn't be a problem: the name xterm propagates to the other end. If you're using a character-oriented display (/dev/ttyvx), however, your TERM variable is probably set to cons25, which many systems don't know. If systems refuse to start full-screen modes when you connect from a virtual terminal, try setting the TERM variable to ansi.

To exit ssh, just log out. If you run into problems, however, like a hung network, you can also hit the combination Enter ~. Enter, which always drops the connection.

Access without a password

Sending passwords across the Net, even if they're encrypted, is not a complete guarantee that nobody else can get in: there are a number of brute-force ways to crack an encrypted password. To address this issue, ssh has an access method that doesn't require passwords: instead it uses a technique called public key cryptography. You have two keys, one of which you can give away freely, and the other of which you guard carefully. You can encrypt or decrypt with either key: data encrypted with the public key can be decrypted with the private key, and data encrypted with the private key can be decrypted with the public key.

Once you have these keys in place, you can use the challenge-response method for authentication. To initiate an ssh connection, ssh sends your public key to the sshd process on the remote system. The remote system must already have a copy of this key. It uses it to encrypt a random text, a challenge, which it sends back to your system. The ssh process on your system decrypts it with your private key, which is not stored anywhere else, and sends the decrypted key back to the remote sshd. Only your system can decode the challenge, so this is evidence to the remote sshd that it's really you.

By default, the private key for Version 1 of the protocol is stored in the file ~/.ssh/identity, and the public key is stored in the file ~/.ssh/identity_pub. For Version 2, you have a choice of two different encryption schemes, DSA and RSA. The corresponding private and public keys are stored in the files ~/.ssh/id_dsa, ~/.ssh/id_dsa.pub, ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub respectively. If you have the choice between DSA key sand RSA keys for protocol Version 2, use DSA keys, which are considered somewhat more secure. You still should have an RSA key pair in case you want to connect to a system that doesn't support DSA keys.

There's still an issue of unauthorized local access, of course. To ensure that somebody doesn't compromise one system and then use it to compromise others, you need a kind of password for your private keys. To a void confusion, ssh refers to it as a passphrase. If ssh finds keys in the ~/.ssh directory, it attempts to use them:

$ ssh hub
Enter passphrase for key '/home/grog/.ssh/id_rsa':    (no echo)
Last login: Sat Jul 13 17:27:33 2002 from wantadilla.lemis
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
     The Regents of the University of California. All rights reserved.
FreeBSD 5.0-STABLE (HUB) #7: Thu Jun 26 12:44:34 PDT 2003
(etc)