Section 10.1. What Can Text-Mode Logins Do?

10.1. What Can Text-Mode Logins Do?

In today's world of POP email, the World Wide Web, file shares that are virtually indistinguishable from hard drives (from a user's perspective), and so on, text-mode login protocols may seem quaint at first. Nonetheless, these tools still have life left in them, at least in some environments. Text-mode user access can still be a useful way to enable users to get work done, and such access is particularly helpful for remote administration of Linux systems, which can typically be administered entirely using text-mode tools. Assuming you've decided that text-mode logins are worth implementing, you should know a bit about the most common protocols so that you can pick the one that's right for your needs.

10.1.1. Remote Text-Mode User Access

Most Linux users today run GUI programs using the X Window System (or X for short). This wasn't always the case, though. In Linux's early years, most programs were text mode. Some of these programs were quite powerful, having been inherited from earlier Unix systems. Many of these programs have been maintained over the years and can still be useful tools for remote text-mode users. Indeed, even users who run X often make heavy use of text-mode tools, running them in xterm or similar command-line windows under X.

Many text-mode user programs are also useful, or even required, for administrative functions.

What, then, are these programs? Examples of some of the more notable programs and classes of programs include:

Text editors: Text-only text editors for Linux are plentiful and include such stripped-down tools as vi, jed, and nano, as well as much more powerful programs such as Emacs.
Document processing: Word processing as we know it today is usually implemented in GUI programs, but you can create, edit, and print documents using a text editor and a text-mode document processing system such as LaTeX. Indeed, some people prefer using such tools to using the more popular word processors. Even for word-processor fans, a few are available in text mode, although they tend to be old. The commercial WordPerfect for Linux, although best-known as a GUI program, had a text-mode variant, for instance.
Office tools: In addition to word processing, other traditional office tools are available in text-only versions. For instance, the SC and SS spreadsheets run entirely in text mode. Even some graphics programs run in text mode, but typically just to convert between file formats and the like.
Development tools: Most Linux compilers are, first and foremost, text-mode tools. Although GUI frontends are available, the GNU Compiler Collection (GCC) and many other development tools run just fine from text-mode logins.
Network tools: Most network protocols have text-mode clients available. A Linux system can function as a limited door onto the Internet for a network that's otherwise restricted in access; users can log into a Linux system and run mail clients such as Pine and Mutt, FTP clients such as ftp, and even web browsers such as lynx.

Overall, most tasks that Linux can accomplish using GUI tools can also be accomplished in text mode. The main exception is graphics-intensive tasks like bitmap graphics editing.

Why, though, would users want to restrict themselves to text mode? Sometimes the text-based tools simply are the best available, at least for particular users. For instance, a user who's accustomed to creating documents in LaTeX and who doesn't need or want the GUI add-ons might be quite happy to do so from a remote system using a text-mode login protocol. In many cases, though, the question boils down to one of available bandwidth, and hence speed. Text-mode access tools are quite zippy on modern networks, and they're even tolerable on 56-Kbps dial-up connections. GUI access tools, by contrast, are bandwidth hogs. They may work reasonably well on fast and unsaturated local network connections, but over slow links or when the local network is under heavy load, GUI tools can become intolerably slow. Thus, one common reason to use text-mode tools is to make remote use of a Linux system tolerable over slow or heavily loaded network links. For instance, you might give users who travel frequently remote login access to a Linux box, from which they can access your network's files, read email, and so on. To be sure, using other protocols directly from the remote systems might be an equally good or even superior solution in many cases, but using the remote login protocol can help simplify matters and may help security, particularly if you use a protocol that incorporates encryption.

Another reason to implement text-mode login tools is to provide a necessary "foot in the door" for running GUI login tools. In particular, some methods of running X remotely or starting a VNC session require that users have text-mode access to the Linux system. This issue is covered in more detail in Chapter 11.

10.1.2. Remote Text-Mode Administration

A second broad class of reasons to use text-mode login tools is to enable remote administration of a Linux computer. All major Linux distributions are built around configuration files that you can edit with a text editor, so administering them via a text-mode login is almost always an option. Even when distributions provide GUI administrative tools, they also often supply text-based equivalents. For instance, SuSE's YaST2 GUI tool has a text-based counterpart in YaST, and most of Red Hat's and Fedora's small administrative applications come in both GUI and text-based versions. Remote administration has many more specific types of application:

Headless servers: You can run a server computer without a monitor, and sometimes even without a keyboard, as a way to save space and money. Such systems must be administered remotely, although you may have a choice of text-based, GUI, web-based, or perhaps other methods of remote administration.
Side-by-side comparisons: Sometimes it's helpful to have access to two systems' configurations on one screen. You can open a pair of xterm windows in a GUI window, use a text-mode access protocol to log into one system from another, and compare the systems' configurations in the two windows. This can be a handy approach even if the two computers are just a few feet apart.
Administering desktop systems or widely separated servers: If your site uses Linux desktop systems, remote administration of those systems can be a real time-saver. Rather than run around your site to investigate problems, you can log into computers remotely and run text-based diagnostic commands. The same approach is helpful if you've got multiple server computers in different locations.
Inaccessible servers: Sometimes a computer must be located in a physically inaccessible location. A common example is a colocated web server, which is housed at an Internet Service Provider's (ISP) office to gain access to that ISP's high-speed Internet connection. Systems housed at branch offices, used for automated remote data collection, and so on also qualify in this category.
Emergency situations: If you're at home or on vacation when a dire problem occurs on a Linux system at work, you may be able to use a remote text-mode protocol to quickly fix the problem. Of course, chances are you won't like getting the call during your off hours, but being able to fix the problem remotely beats having to go in to work on your day off!
Telecommuting: Just as ordinary users can telecommute with the help of remote access tools, you may be able to do the same with your system administration duties.

Text-mode access protocols are arguably more appealing for remote system administration than for ordinary work. Because of Linux's text-based heritage, administrative tools are exceptionally well represented in text-based versions. Also, many Linux system administrators are as or more comfortable with text-based tools than with GUI tools. The same bandwidth and speed issues apply to remote system administration as apply to remote end user access.

10.1.3. Tools for Remote Text-Mode Access

If you've decided you want to implement remote text-mode access, your next decision is how to do it. Two protocols, Telnet and SSH, dominate remote access today. Other tools are available to do the job, though, and in some cases they're appropriate. Overall, the most common tools are:

Telnet: This is one of the oldest protocols in common use, and also one of the simplest. It basically sets up a two-way text link, in which the characters you type are passed over the network to the remote system, and remote program responses are relayed to your screen. Basic Telnet supports very little in the way of encryption or other complications to this simple model. This simplicity is Telnet's major flaw; without encryption, data passed over a Telnet session can easily be sniffed by computer miscreants on your network or on intervening networks if the client and server aren't on a single network.
Kerberized Telnet: The Telnet clients and servers that ship with Kerberos implementations support data encryption, although the encryption features aren't always implemented automatically. If your network already uses Kerberos, switching to Kerberized Telnet makes sense and can provide much-needed encryption to these sessions. Chapter 9 covers Kerberos and its version of Telnet.
rlogin: The rlogin protocol, named after its client command, is an extremely simple remote access tool. It provides no-password access from an account on one system to a like-named account on another system. This security model is, by modern standards, appallingly lax, so rlogin is almost never used today. (A Kerberized variant is much better in this respect, though.)
rsh: A variant of rlogin, this command enables you to run a single program from a remote computer on your local computer. Like rlogin, its security is poor, so it should almost never be used.
SSH: SSH may be the most popular remote text-mode access tool in use, having displaced Telnet as the tool of choice. SSH's most important advantage over Telnet is that it supports encryption, making the protocol a much safer choice than Telnet. SSH also supports tunneling non-SSH protocols (including X sessions), file copying (via the scp command), and the ability to replace rsh's functionality.
RS-232 serial connections: This tool isn't a network protocol; instead, it's a method of physically connecting two computers. In days of old, mainframe computers served a collection of potentially dozens of dumb terminals, which were connected to the mainframe via RS-232 serial connections, or something similar. Linux can work in the same way, which can give two users access to one computer if you've got an old dumb terminal or if you run a terminal emulator on another computer (even an extremely old one). RS-232 connections are usually fairly secure because they're direct physical connections without intervening networks. They're inflexible, though; you can't easily use them to connect to a server from other arbitrary systems.

This chapter emphasizes the Telnet and SSH servers because they're very popular. Kerberized Telnet is described briefly in Chapter 9.

You should never use Telnet or any other unencrypted remote access tool to transfer sensitive data. (Remember that data travels both ways; for instance, your password is retrievable from a Telnet login session even though it's not echoed back to your screen.) Although this chapter describes Telnet for the sake of completeness, I don't recommend using it unless you absolutely can't use SSH for some reason. This caution applies even more strongly to use of Telnet for remote system administration, which necessarily involves transferring the highly sensitive root password.