Linux in a Windows World/Remote Login Tools/Remote Text-Mode Administration and Use

From WikiContent

< Linux in a Windows World | Remote Login Tools
Revision as of 21:46, 11 March 2008 by Docbook2Wiki (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Linux in a Windows World

The simplest form of remote login access is text-mode access, in which only textual data and a few simple control codes are exchanged between computers. Text-mode access is ideal for running text-mode programs, and it has the added advantage of consuming little in the way of network bandwidth, which makes it suitable to use across slow network links, such as dial-up Internet connections. This type of access can be very handy for administering a Linux system; Linux can be configured entirely using text-mode tools, so text-mode login methods can be a good way to do the job remotely. Perhaps your servers are scattered about the building (say, print servers located near the printers they manage) and you need to make changes without running around. Perhaps you need to log in over a dial-up line or even from a PDA while on the road. In such cases, remote administration is critical, and the ability to do the job without a lot of flashy (and bandwidth-intensive) GUI overhead can help you get the job done quickly. Remote text-mode access can also be useful for running many nonadministrative programs, although most ordinary users are more comfortable with GUI tools.

This chapter begins with a look at the principles behind text-mode logins—tools for implementing it and why you might want to use it. This chapter then looks at two common protocols for implementing remote text-mode access, Telnet and the SSH, with a focus on Linux configuration. This chapter concludes with information on Windows tools for handling remote text-mode access, including both clients and servers.

Contents

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.

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.

Tip

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.

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.

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.

Warning

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.

SSH Server Configuration

In most cases, SSH is the preferred remote text-mode access method; this protocol implements security at its core, and it's become almost as widely available as Telnet. SSH is, though, a much more complex protocol, and its server program implementations reflect this fact. Configuring and running an SSH server is therefore a more complex task than configuring and running a Telnet server, although the default SSH server configurations for most Linux distributions require little work to get running.

SSH Server Options for Linux

If you want to use SSH, you must first decide which of several SSH server packages to use:

SSH Tectia
SSH was developed by a company called SSH Communications Security (http://www.ssh.com), which sells its commercial SSH server under the name SSH Tectia. (Versions prior to 4.0 used the name SSH alone.)
OpenSSH
This may be the most popular SSH server in Linux. It was originally developed in association with OpenBSD, but most Linux distributions include it under the package name openssh or something similar. Its official web site is http://www.openssh.org, and it's distributed under the BSD license.
FreSSH
This server, headquartered at http://www.fressh.org, is an independent SSH implementation that's distributed under the BSD license.
lsh
For GPL fans, lsh is an SSH implementation under that license. You can learn more at http://www.lysator.liu.se/~nisse/lsh/.

Any of these servers should work well and interoperate with common SSH client programs, but their configuration details differ. This chapter describes OpenSSH configuration, which is similar to SSH Tectia in its configuration file locations and formats. If you elect to use FreSSH or lsh, you need to consult your server's documentation. If you need more information on SSH than is in this chapter, consult the package's manpages or a book on the subject, such as SSH, The Secure Shell: The Definitive Guide (O'Reilly).

Tip

SSH has seen protocol version changes over time. As I write, SSH Version 2 is the latest major protocol release in widespread use. Older systems may require use of SSH Version 1, but its use isn't recommended. Major SSH servers should support both protocols, but configuration options are available to disable one or the other version.

Configuring an SSH Server

Once you've installed your SSH server package, you should look for its configuration file: /etc/ssh/sshd_config. Do not confuse this file with the configuration file for your SSH client program, /etc/ssh/ssh_config. This one-character difference in filenames can lead to a great deal of confusion if you don't notice it.

The OpenSSH configuration file format is fairly straightforward: non-comment lines begin with a keyword and end with an argument. Comment lines are denoted by a leading hash mark (#). For the most part, the default SSH configuration should work reasonably well for most installations; however, you might want to look through the file to be sure everything's set reasonably. Pay particular attention to these options:

AllowTcpForwarding
This option defaults to yes, which tells the server it may forward connections to ports specified by the client. This is a useful feature if you want to use SSH to tunnel other protocols. Disabling it might seem to be one way to improve security, but if users have shell access, they can install their own port forwarders, so disabling this feature isn't likely to provide any significant security benefit.
AllowUsers
You can provide a list of users who are given access by using this option. This may be a handy security tool if only some users should have remote access. (A similar option for groups is called AllowGroups.)
Banner
If you pass a filename to this option, OpenSSH displays its contents to the client before authenticating the user.
Compression
This option takes a yes or no argument, which tells the server whether to accept a client request to compress data transfers. The default value is yes, which is usually desirable; however, if your server has a weak CPU, you might want to set this value to no.
DenyUsers
This option is the opposite of AllowUsers; you can blacklist specific users by listing them as arguments. A similar option for groups is DenyGroups.
GatewayPorts
This option defaults to no, which causes remote port forwardings to bind only to the loopback address (127.0.0.1). For some tunneling applications, though, these forwards should bind to all local network addresses, which requires this option to be set to yes.
KerberosAuthentication
If set to yes, this option tells SSH to try to validate a user's password with the help of a Kerberos server. The default value is no.
ListenAddress
This option takes a hostname or IP address, optionally followed by a colon and a port number (as in 192.168.1.7 or 192.168.1.7:22) to specify the network hardware to which the server should bind. If this option is not specified, SSH binds to all network interfaces. To bind to multiple interfaces but not to all of them, you can provide multiple ListenAddress lines.
LogLevel
This option determines how much information the server logs. Possible values, in increasing log level, are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3, with the default being INFO.
PasswordAuthentication
This option, which defaults to yes, determines whether the system should accept passwords for authentication.
PermitRootLogin
This option tells SSH whether and under what circumstances to accept direct root logins. The default value is yes, but you may want to set this option to no to reduce the risk of abuse. (You can still log in as a normal user and run su, sudo, or other tools to administer a Linux system.) Intermediate values are without-password, which disables password-based authentication in favor of public key authentication, and forced-commands-only, which disables root logins but permits public key authentication only for running specific commands. That can be handy for enabling remote backups or other tasks that require running specific programs as root.
Protocol
You can tell SSH which protocol levels to support by passing their numbers. If you want to support both Versions 1 and 2, you must separate the numbers with a comma, as in 2,1. Order is unimportant; protocol preference is set by the client.
PubkeyAuthentication
This option takes a yes or no value and defaults to yes. It determines whether the server accepts public key authentication. This option affects SSH Version 2 only.
RSAAuthentication
This option is similar to PubkeyAuthentication, but if affects protocol Version 1 only. (SSH protocol Versions 1 and 2 require different public key file formats.)
UseDNS
If set to yes (the default), this option causes the server to look up a client's hostname using its IP address and then look up the IP address from that hostname and check that it matches the IP address the client uses. This improves security because it makes it harder for an attacker to pretend to be an authorized client, however, this option can also cause problems if your DNS configuration is broken or slow.
UsePAM
This option defaults to no, but you may need to change it to yes if you want to use an NT domain controller, LDAP server, or other advanced authentication tools, as described in Appendix A. If you do this, the documentation recommends also setting PasswordAuthentication to no.
X11Forwarding
This option, which defaults to no, tells SSH not to forward X traffic. This configuration helps protect the client's X server from attack; however, to use SSH as part of a remote X access method, as described in Chapter 11, you must change this option to yes.

SSH in general, and the OpenSSH server implementation in particular, is complex enough that this list is incomplete. If you need to perform more advanced tasks, you may need to consult the relevant documentation.

Launching an SSH Server

You can launch an SSH server using a super server, much as you launch a Telnet server; however, SSH is slower to start up than is Telnet, so the more common approach is to start SSH using a SysV or local startup script. Most Linux SSH packages include such a script, typically called ssh or sshd and stored in /etc/init.d or /etc/rc.d/init.d. To start or stop the SSH server on a one-time basis, pass the start or stop option to the SysV startup script, and most distributions respond with some sort of status report:

# /etc/init.d/sshd start
 * Starting sshd...                      [ ok ]

Most distributions provide a tool called chkconfig to manage which servers start in common runlevels; to tell your system to start the SSH server, type a command such as chkconfig --add sshd. Consult distribution-specific documentation if this command doesn't work or if you need to perform other special tasks. Instead of chkconfig, Gentoo Linux uses rc-update; you'd type rc-update add sshd default to add the SSH server to the default runlevel.

Once the server is running, you should be able to access it from another computer:

$ ssh linnaeus@mandragora.pangaea.edu
Password:
Last login: Mon Dec 27 11:24:40 2004 from pointer.example.com
Have a lot of fun...
linnaeus@mandragora:~>

This example uses the username@hostname form of address to specify both the username and the server's hostname. In many cases, you can omit the username@ part, though; Linux's ssh clients use your current username if you don't specify one. To execute a single command rather than log into the remote system, specify the command after the other options, as in ssh root@mandragora.pangaea.edu shutdown now -r to shut down and reboot the remote computer. (Note that this particular example requires that direct root access be enabled.)

Telnet Server Configuration

As one of the oldest and most popular remote text-mode login tools available, Telnet is an excellent choice for compatibility—just about every OS with a TCP/IP stack comes with a Telnet client, so using a Telnet server under Linux makes your system accessible from just about everywhere. Telnet's unencrypted nature, though, is a major drawback. Thus, you should use Telnet only when you have no other choice (say, because of limited client OS software options) or on highly protected local networks.

Telnet servers are simple and easy to configure in Linux; the worst complication is knowing whether you're using the inetd or xinetd super server. Although Telnet's security features are severely lacking, you may be able to improve matters using a Kerberized Telnet or by implementing limited access controls in your super server.

Launching a Telnet Server

All major Linux distributions ship with a Telnet server, although many don't install it by default. Likely package names include telnetd, telnet-server, netkit-telnetd, telnet-bsd, and utelnetd, among others. (Kerberized or other encrypting variants are also available.) The server program itself is usually called telnetd or in.telnetd, and is usually stored in /sbin or /usr/sbin. Although Telnet servers come from several different sources, basic configuration and use is fairly consistent.

Typically, Telnet servers are launched from super servers—usually inetd or xinetd. If you're not sure which super server your system runs, type ps ax | grep inetd and examine the output for a process called inetd or xinetd. If neither is present, you may need to install, or at least launch, your distribution's super server package.

The inetd super server is controlled through the /etc/inetd.conf file, which devotes one line to each server it manages. A typical Telnet server configuration looks something like this:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

This example calls the server via the TCP Wrappers (tcpd) program, which provides added security options. An equivalent configuration for a system that uses xinetd doesn't use TCP Wrappers because xinetd incorporates features similar to those provided by TCP Wrappers. Linux distributions that use xinetd typically place configurations for individual servers in files located in /etc/xinetd.d; the Telnet server's file (typically called telnet or telnetd) looks like this:

service telnet
{
   disable      = no
   socket_type  = stream
   protocol     = tcp
   wait         = no
   user         = root
   group        = root
   server       = /usr/sbin/in.telnetd
   server_args  =
}

Tip

Many systems disable Telnet by default in the super server configuration files. In the case of inetd, the line defining the Telnet server is commented out by placing a hash mark (#) at the start of the line. To use Telnet, you must remove that character. In xinetd, the disable = yes option disables the server; this line must be changed to read disable = no to activate the server.

Whether you launch the server via inetd or xinetd, you can add a few options that modify the server's behavior. In the case of inetd, you place these options at the end of the Telnet server's configuration line; for xinetd, you place them on the server_args line, which you may need to add to the configuration file. Some of the more common and useful Telnet server options include:

-h
Telnet normally sends a banner to clients, announcing some basic information about the system, which is likely to include your distribution and kernel version number. The -h option disables the display of this banner.
-U
This option causes the server to block connections from computers whose IP addresses can't be resolved to hostnames. This can slightly improve your security if you're certain that all legitimate clients should have hostnames that can be obtained from their IP addresses.
-L program-file
Ordinarily, Telnet calls the standard Linux login program to authenticate users. This option enables you to substitute another program, which might be handy if you have special authentication needs or want to use Telnet for some specialized non-login purpose. For example, you can have the server launch a specialized network diagnostic tool rather than give users conventional login access.

This list of options isn't complete, and, in fact, the options may vary from one Telnet server to another, so you may want to consult your local documentation for details on other options. Many installations work well with no Telnet server options, but to improve security slightly, you might want to use -h and, if it won't cause problems for legitimate users, -U.

Once you've finished configuring your super server, you must restart the super server or force it to reload its configuration. In most cases, passing the restart or reload option to your super server's SysV startup script will do the trick:

# /etc/init.d/xinetd reload
               

Thereafter, the system should be accessible via Telnet. If you have problems logging in, consult the server's log files; chances are the super server or the Telnet server will log error messages concerning login failures or an inability to launch the Telnet server.

Telnet Server Security Concerns

As you may be tired of hearing by now, Telnet's main flaw is its lack of security features—in particular, its lack of encryption. This limitation has implications you should understand, but there are also ways to add encryption. Another security concern with any remote-access protocol is controlling the computers that can connect to the server. Because Telnet is typically run from a super server, you can use its features, or those of tools that the super server calls, to control remote access.

Encryption

The basic Telnet provides no encryption features. This means that all data transferred between the client and the server (in both directions) is unencrypted. This flaw is most important for passwords—although you don't see your password echoed on the screen, it can be easily retrieved should your Telnet session be intercepted. This risk is very serious for ordinary user accounts and completely unacceptable for root logins.

Tip

Because of the risks of password interception, most Linux distributions configure themselves to forbid direct root logins via Telnet.

Even if login password interception isn't an issue, Telnet's unencrypted nature can be a problem during login sessions. If you read a sensitive email in a Telnet session, use su to acquire root privileges, or use SSH from your Telnet session to another computer, you'll be sending sensitive data in the clear.

Various methods of adding encryption to Telnet have been developed. Typically, the Telnet protocol is extended with an encryption layer. The Kerberized version of Telnet, described in Chapter 9, is one somewhat common example. Another approach is to encrypt Telnet traffic with the Secure Sockets Layer (SSL) library. The result is packaged with some distributions as telnet-ssl or a similar variant. A third approach is to tunnel Telnet through an encrypting protocol, such as SSH. The disadvantage to all of these approaches is that it requires extra software on both the client and the server, and this software is not as common as is Telnet. In fact, with the SSH tunneling approach, chances are you wouldn't need to use Telnet at all, because SSH is a perfectly good text-mode login tool in its own right.

Controlling access by IP address

Because of Telnet's poor security, if you use it you should employ your super server's or firewall's access control tools to limit who may access the server. For instance, you might want to restrict access to the server to computers on your own local subnet, or perhaps even to just those computers that absolutely need to use Telnet.

In xinetd, which is fast becoming the most common Linux super server, you can limit remote access by adding options to a server's control file in /etc/xinetd.d:

only_from
This option sets a list of hostnames, IP addresses, or address/netmask pairs that are permitted to access the server. All other computers are denied access.
no_access
This option takes addresses much like only_from, but it specifies systems that should not be given access. For Telnet, only_from is likely to be the more useful tool, but you might use no_access to create exceptions to a range of addresses granted access with only_from.
bind
This option tells the server to bind to one interface only. This feature is most useful on routers and other computers with multiple network interfaces; you can bind Telnet to a secure local interface but not to the Interface that's accessible from the Internet. You might also use it to bind exclusively to the localhost (127.0.0.1) interface or to an interface that's used by an emulator, to enable the emulated OS to contact Linux. This parameter takes the IP address of the interface to which you want to bind as an option.
access_times
This option controls access by time rather than by IP address; you specify a time range in the form hh:mm-hh:mm, where each hh is an hour in 24-hour format (between 00 and 23) and mm is the minute.

As an example, you might use the bind and only_from parameters to restrict access to computers on the 192.168.7.0/24 network, if the computer in question has the address 192.168.7.27:

bind      = 192.168.7.27
only_from = 192.168.7.0/24

Tip

Depending on the network settings, the bind and only_from settings may seem redundant; however, they actually perform slightly different tasks. The bind option binds to a physical network card, so if a computer's traffic is being routed in an unusual way or if it's spoofing an address, bind won't be fooled. In this context, only_from might be redundant, or it might not, if traffic from other networks should be arriving on that port. In any event, layered security, in which multiple checks of the same basic restriction are performed, can help improve a system's overall security.

Windows Remote-Login Tools

If Windows systems are to interact with Linux systems via text-mode tools, you must locate matching Windows clients to Linux servers or locate Windows servers for Linux clients. The first task is considerably easier and likely to be more productive than the second; although text-mode Windows login servers do exist, they aren't nearly as useful as Linux remote text-mode login servers because Windows was never designed with this sort of operation in mind.

Locating Client Software

Windows client software for both Telnet and SSH protocols is fairly easy to find. In fact, all versions of Windows that support TCP/IP networking ship with a Telnet client. Type TELNET in a DOS prompt window or select the Telnet item from the Start menu to launch this client.

If you're not satisfied with the features of the standard Windows Telnet server or if you want to use SSH to access your Linux system, you'll need to look elsewhere. One excellent resource is the Free SSH web site's Windows page, http://freessh.org/windows.html, which lists Windows SSH clients and servers, of both the free and the pay variety. Many of these SSH clients can also handle Telnet and other protocols, so they're well worth investigating.

As an example of a Windows text-mode login client, consider PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/). This program can handle rlogin, Telnet, and SSH protocols. When you first launch it, you'll see a PuTTY Configuration dialog box, as shown in Figure 10-1. To open a basic SSH session, type the hostname or IP address of the server in the Host Name (or IP Address) field, check that the Protocol item is set to SSH, and then click Open. The first time you connect, the system will notify you that the server's host key is not cached. This is normal for an initial connection, so click Yes to accept the key. The system will then prompt you for a username and password in the access window and, if you enter them correctly, you'll be in and able to use the remote system.

Figure 10-1. PuTTY enables you to specify many options for your remote login sessions

PuTTY enables you to specify many options for your remote login sessions

For more advanced uses, you can adjust various options by clicking their categories in the list in the Category field of the PuTTY Configuration dialog box. If you regularly use particular settings (including connections to specific servers), you can make the adjustments you want, type a session name in the Saved Sessions field, and click Save to save your settings. Thereafter, double-clicking on the session name launches a session with those settings.

Windows Telnet and SSH Servers

Windows, unlike Linux, was not designed with remote text-mode use in mind. Although Windows has DOS—a text-mode OS—in its history, Windows simply never embraced the notion of remote text-mode access in the way Linux has. Furthermore, Windows is tied more tightly to its GUI for both common user programs and system administration than is Linux, so using it from a text-mode login will tie your hands in terms of the tasks you can accomplish.

These caveats aside, remote text-mode access tools for Windows are available. Because these tools are of limited utility, I don't describe them in great detail, but they do deserve a few pointers. A few of the available servers include:

Cygwin OpenSSH
The Cygwin package includes an OpenSSH server, whose setup and basic operation is documented at http://tech.erdelynet.com/cygwin-sshd.html. This configuration provides access to a Windows system using the Cygwin environment, which resembles a Unix environment but enables you to run many text-mode DOS and Windows programs.
OpenSSH for Windows
This package borrows from Cygwin but doesn't install a full Cygwin environment. As a result, when you log into the server, you'll see a DOS-style C:\> prompt. You can learn more at http://sshwindows.sourceforge.net/.
Georgia Softworks Telnet and SSH
Georgia Softworks (http://www.georgiasoftworks.com) sells a commercial Telnet server for Windows and a commercial SSH server for Windows. These packages provide unusually good terminal emulation; that is, they do a better job than most at enabling you to run text-mode programs that require extensive cursor control, such as text-mode editors.

As noted earlier, the Free SSH site's Windows page (http://freessh.org/windows.html) provides pointers to Windows SSH servers as well as SSH clients, so you can consult it for links to more servers. As a general rule, the free offerings are scarce, but several commercial products are available.

One of the difficulties in using a text-mode Windows remote-access tool manifests itself when you try to run programs that move the cursor around the screen in an arbitrary way, such as text editors. Under Linux, a set of libraries between programs and the screen display handle the translation for any number of display types—a text-mode console, an xterm window, a remote Telnet session, and so on. (In fact, some Windows Telnet and SSH clients provide options that influence how they interact with these libraries by changing their terminal emulation mode, which can improve their ability to handle features such as colored text.) Windows lacks these libraries, so the remote-access server must either implement these translations themselves or ignore the issue. The former is a difficult task, so many servers ignore the issue. The result is an inability to run text-mode programs that do more than display text in a simple linear fashion. For instance, typing EDIT in an OpenSSH for Windows session effectively hangs the session.

Despite these limitations, text-mode login tools for Windows can be handy in some situations; you can run simple tools and scripts that don't rely on GUI components or the more advanced text-mode features. If you have a specific use in mind for the access, you might be able to track down or write a program to do a job, thus saving considerable bandwidth (and, hence, time) that might otherwise be required to use a GUI login tool. You can also use an SSH server as a way to establish encrypted connections to other servers running on the Windows machine, by using SSH's port-forwarding capabilities.

Summary

Remote text-mode logins have been around for a long time, and they remain useful tools, particularly for accessing Linux systems. Ordinary users can use text-mode logins to perform various tasks, but they may be more important as remote administrative tools, enabling you to handle tasks at a distance that would otherwise be tedious or require your physical presence. Telnet has long been a popular remote login protocol, but SSH has eclipsed it, at least in security-conscious circles, because of SSH's support for encryption. Although Telnet variants with encryption are available, they're harder to find than SSH. For the most part, remote text-mode access tools are best used to access Linux from clients that can run just about any OS, but text-mode login servers for Windows are also available. These tools are much more limited in their utility, however, because of the more GUI-centric nature of Windows user programs and system administration tools.

Personal tools