By William von Hagen, Brian K. Jones
Book Price: $29.95 USD
£20.99 GBP
PDF Price: $23.99

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Linux Authentication

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Security is a primary concern of any sysadmin, especially in today's completely connected network environments. After locking down networks and systems to minimize the number of opportunities intruders have to access your machines (as discussed elsewhere in this book), providing secure mechanisms to enable users to log in on your machines is critical to their security. Let's face it—by design, anyone with physical or network access to a login prompt on one of your machines usually has a few chances to try to crack someone's login and password in order to gain access.

Many organizations try to secure logins simply by assigning passwords that look like line noise or TECO commands. Unfortunately, this strategy addresses only one aspect of authentication and has the nasty side effect of causing most people to write down their passwords, since only The Amazing Kreskin could remember them. So what are the alternatives? As explained in this chapter, flexible authentication mechanisms such as Pluggable Authentication Modules (PAMs) enable the login sequence to invoke multiple security checks, beyond just a password, to help minimize the chances of unauthorized logins. Similarly, networked authentication mechanisms can enhance login security by centralizing authentication checks on secure servers and can provide other organizational benefits, such as encrypted network communications and providing login information for different operating systems, not just your Linux machines. Networked authentication mechanisms inherently benefit sysadmins by providing one true location for creating and managing information about your users. Of course, you still have to convince your users not to use their birthdays, their license plate numbers, or the names of their significant others as passwords—but we can't really help you there.

The hacks in this chapter discuss various ways of dealing with the whole spectrum of user authentication issues, ranging from ways that a sysadmin can use to quickly disable all logins or specific accounts, through some cool tweaks you can do to your local password file, to networked mechanisms you can use for centralized authentication of different types of systems. Providing secure authentication mechanisms for your systems doesn't have to be a nightmare—let the hacks in this chapter teach you a few tricks and choose the authentication mechanism that's right for the computing environment for which you're responsible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Hacks 1–9: Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Security is a primary concern of any sysadmin, especially in today's completely connected network environments. After locking down networks and systems to minimize the number of opportunities intruders have to access your machines (as discussed elsewhere in this book), providing secure mechanisms to enable users to log in on your machines is critical to their security. Let's face it—by design, anyone with physical or network access to a login prompt on one of your machines usually has a few chances to try to crack someone's login and password in order to gain access.

Many organizations try to secure logins simply by assigning passwords that look like line noise or TECO commands. Unfortunately, this strategy addresses only one aspect of authentication and has the nasty side effect of causing most people to write down their passwords, since only The Amazing Kreskin could remember them. So what are the alternatives? As explained in this chapter, flexible authentication mechanisms such as Pluggable Authentication Modules (PAMs) enable the login sequence to invoke multiple security checks, beyond just a password, to help minimize the chances of unauthorized logins. Similarly, networked authentication mechanisms can enhance login security by centralizing authentication checks on secure servers and can provide other organizational benefits, such as encrypted network communications and providing login information for different operating systems, not just your Linux machines. Networked authentication mechanisms inherently benefit sysadmins by providing one true location for creating and managing information about your users. Of course, you still have to convince your users not to use their birthdays, their license plate numbers, or the names of their significant others as passwords—but we can't really help you there.

The hacks in this chapter discuss various ways of dealing with the whole spectrum of user authentication issues, ranging from ways that a sysadmin can use to quickly disable all logins or specific accounts, through some cool tweaks you can do to your local password file, to networked mechanisms you can use for centralized authentication of different types of systems. Providing secure authentication mechanisms for your systems doesn't have to be a nightmare—let the hacks in this chapter teach you a few tricks and choose the authentication mechanism that's right for the computing environment for which you're responsible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Disable User Accounts Instantly

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In a crisis, here's how to quickly disable a user account, using only a text editor.

Sooner or later every system administrator gets the call to disable a user's account. Regardless of whether this is due to termination or for general security reasons, you have to move quickly to satisfy the Human Resources department or layer of management that's on the other end of the line. If you're used to graphical tools for user management, this can take a little while, but luckily there's a quick and easy solution to this request that just involves a text editor.

On older Unix systems passwords were stored in the /etc/password file, but they were moved to the /etc/shadow file (which is readable only by the root user) on more recent systems to prevent non-root users from having access to the encrypted form of a user's password, for security reasons. Most Linux systems that use local authentication store passwords in the /etc/shadow file, though some still use /etc/passwd as an artifact or for compliance with aging applications. If the second colon-separated field in each entry in /etc/passwd contains an x, your system is using the /etc/shadow file to hold password information. If you see other characters between the first and second colons, your system is still storing its password information in the /etc/passwd file.

To quickly disable accounts on a Linux file server or on a user's desktop machine, bring up /etc/shadow in a text editor and insert an asterisk (*) as the first character in the second field of the file (after the first colon), which is where the password is stored. This prevents subsequent logins but leaves the existing password intact. If circumstances reverse themselves and you're asked to re-enable the user's account, you can simply remove the asterisk to re-enable logins with the existing password. This is similar to the approach taken by the usermod -L user command, which inserts an exclamation mark (!) at the beginning of a user's password entry to lock out that user. Actually, if your system provides the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Edit Your Password File for Greater Access Control

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With just a few one-line text file edits, you can control who can access your servers.

I can't cite statistics, but my experience in lending a hand to friends and clients has led me to the conclusion that most sites have an "all or nothing" approach to creating and managing user accounts on their machines. If the site uses NIS, their nsswitch.conf file says to use NIS for user account information. If the site uses LDAP, they use LDAP for user account information. The problem here is that this implies that every single account in the directory is actually a valid account on any machine, whether those users belong there or not.

Of course, there are firewalls, router ACLs, and all manner of security appliances and software between servers and users who shouldn't have access to them—but data centers are run by humans, and humans make mistakes, especially in large, complex networks. Mistype the VLAN tag on a switch port, for example, and all of a sudden anyone from Engineering can SSH to your production application server. This hack shows you how a few simple text edits will allow you to limit which users in an NIS directory can access the local machine.

The entries in the /etc/nsswitch.conf file on a Linux system determine how it resolves requests for information about users, groups, and other host information. Let's concentrate on just the passwd line. If you're using NIS, it might look something like this:

	passwd files nis

This means that when the system is trying to find information about a user account, such as the user's login shell or what name a numeric UID maps to, it'll first look in /etc/passwd, and then fall back on NIS. If a user is listed in either of these resources, it's a valid account and (barring any other protections) the operation succeeds.

But suppose you want only a handful of people to have valid accounts on the machines, instead of everyone in the entire NIS domain. We can do that! As an example, let's add two lines to the bottom of the /etc/passwd file:

	+@admins
	+jonesy

The first line makes all the users in the admins netgroup valid accounts on this machine. The second line makes

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Deny All Access in One Second or Less

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Here's a safe way to keep out all users while doing temporary maintenance or troubleshooting.

All administrators eventually need to have a machine running in full multiuser mode, with all services running, but at the same time completely deny login access to the machine. This is usually for the purpose of troubleshooting a problem, testing a new software installation, or performing maintenance or software upgrades. There are a couple of really quick ways to do this.

The first method is by far the quickest. Just run the following command (as root):

	# touch /etc/nologin

This will deny access to anyone trying to log in to the machine. You'll want to be sure to keep an active login session on the machine after you create this file or make sure that root is allowed to log in on the local console or via SSH, since a root login will bypass this mechanism. You'll know it's working because the logs for some services will tell you that access was denied because of the presence of the nologin file. Others will just say "failed password."

This method can be improved through the use of a nologin.txt file, where you can put some text that users will see when they try to log in. If you have a scheduled downtime, for instance, you can put the details into this file so that users will get a friendly reminder that the machine is unavailable during the downtime window.

The second method works only if the services you're running are linked against libwrap, in which case you can very quickly cut off all access to the machine. To check that a service is linked against libwrap, use the ldd command on the binary for the service. For example, to make sure my SSH service is linked against libwrap, I've done the following:

	# ldd /usr/sbin/sshd
			linux-gate.so.1 => (0x004ab000)
			libwrap.so.0 => /usr/lib/libwrap.so.0 (0x0072f000)
	…(lots deleted)

The above output shows all the libraries sshd is linked against, and the path to the library file being used. Clearly, libwrap is linked here. Once you've confirmed that this is the case for the other services you're running, you're ready for the next step.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Customize Authentication with PAMs

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Modern Linux systems use Pluggable Authentication Modules (PAMs) to provide flexible authentication for services and applications. Here are the gory details you'll need in order to use PAMs to quickly and flexibly secure your systems.

Many Linux applications require authentication of one type or another. In days gone by, each authentication-aware application was compiled with hardwired information about the authentication mechanism used by the system on which it was running. Changing or enhancing a system's authentication mechanism therefore required all such applications to be updated and recompiled, which is tedious even when you have the source code for all of the relevant applications on your system.

Enter PAMs, which provide a flexible and dynamic mechanism for authenticating any application or service that uses them. Applications or services compiled with the Linux-PAM library use text-format configuration files to identify their authentication requirements. Using PAMs on your system lets you modify authentication requirements or integrate new authentication mechanisms by simply adding entries to the PAM configuration file that is used by a specific application or service.

Though the information contained here may seem like overkill at first glance, knowing about PAMs and how PAM configuration files work is necessary background for the next four hacks, which explain how to integrate specific types of modern authentication into your Linux system without rewriting or recompiling the wheel. Read on, sysadmins!

PAMs are shared library modules that are automatically loaded by applications that were compiled with the primary Linux-PAM authentication library. Applications that use PAMs (or PAM modules, are they're sometimes called) are typically referred to as PAM-aware applications.

PAMs satisfy different parts of the authentication requirements for PAM-aware applications, much like reusable code and libraries do for applications in general. For example, a PAM-aware version of the login program can invoke a variety of PAMs that check things such as whether the user logging in as root is on a terminal listed as a secure terminal, whether users are allowed to log in on the system at the moment, and other similar authentication requirements. Because PAMs are shared library modules, a PAM-aware version of the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Authenticate Linux Users with a Windows Domain Controller

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To a busy sysadmin, centralization is usually more important than philosophy.

Much has been made in the Linux press about using Samba to bridge the gap between Linux/Unix and SMB/CIFS environments. Samba is not just one of the most impressive pieces of open source software ever—it's also as impressive a job of reverse engineering as "Hacking the Xbox."

However, using Samba for authentication is often more of a philosophical point than an organizational need. Frankly, if you already have a huge, well-designed, functional Windows environment that supports authentication, groups, ACLs, and Exchange (to name a few "popular" Windows services), converting all that to Linux can be more work than it's worth. If you're just starting to integrate Linux boxes into your user desktops in a coherent fashion, why not swim against the standard Linux tide and configure the login mechanisms on your Linux boxes to use the authentication provided by your existing Windows domain controllers? You can always convert them later, when your yearly ransom demand from Microsoft arrives.

To integrate Windows domain and Linux authentication, you'll need to have the PAM, samba-winbind, and smb-client packages installed on your system. The core pieces of software that you'll need are the daemon that enables you to communicate with a Windows domain controller, known as the winbindd daemon (usually installed as /usr/sbin/winbindd), a correctly configured /etc/samba/smb.conf file (used by the winbind daemon to obtain information about your domain and domain controller), and the PAM for domain authentication through this daemon (/lib/security/pam_winbind.so). The winbindd daemon and the pam-winbind.so module are both provided in the samba-winbind package, though to use the PAM you must have the PAM package installed and working on your system. The current versions of these packages at the time this book was written were pam-0.78-8, samba-winbind-3.0.13-1.1, and samba-client-3.0.13-1.1.

Of course, if your environment has enough Windows dependencies to make you want to authenticate your Linux boxes using Windows, you're probably already using Samba to access your Windows shares from your Linux system or your Linux filesystems from your Windows systems. Nowadays, most Linux systems come with Samba installed. To get complete support for Windows domain authentication, you'll want to make sure your system is running Samba 3.x or better. If you're using a package manager, you can run the command

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Centralize Logins with LDAP

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Creating individual accounts on individual machines is a thing of the past: centralize authentication information and more by using a directory server.

The Lightweight Directory Access Protocol (LDAP) provides a hierarchical collection of information that can be accessed over a network. LDAP is an example of a directory service. In this context, the term directory refers to a central information resource (such as a telephone directory or network-accessible address book) but also leverages the idea of hierarchical directory structures. LDAP directories are essentially simple, hierarchical databases that are accessed using keys that identify the portions of the directory hierarchy to traverse to locate a specific unit of information.

The core idea of hierarchical elements and attributes is easy to understand and work with, and it should be familiar to users of similar information models, such as XML. The LDAP protocol is also independent of the underlying storage model used, making it easy to map LDAP data into existing databases or migrate to new, smaller database models.

Like all directory services, LDAP is a client/server technology. Clients can either query or upload information to an LDAP server. In the case of a query, the LDAP server either responds directly or forwards the query to another LDAP server, which repeats the "respond or forward" process. The OpenLDAP project (http://www.openldap.org ), where most Linux LDAP development now takes place, is the source of the software discussed in this hack.

Using LDAP in your environment requires that you have a few basic packages installed on your systems, or that you build and install the OpenLDAP software from scratch. If you need to build it yourself, you can download the latest version of the full OpenLDAP package from http://www.openldap.org/software/download. If your Linux systems use a package management system, you'll need to install:

• An OpenLDAP client on all your systems (including the server, for debugging purposes). These packages usually have names like openldapclient or openldap2-client

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Secure Your System with Kerberos

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can heighten the security of any network by using Kerberos for secure network authentication and encrypted communications.

Kerberos is a distributed authentication and communication service originally developed at the Massachusetts Institute of Technology (MIT). Kerberos provides secure authentication and communication for client/server applications by using strong cryptography to enable clients to prove their identities to servers over the network.

Kerberos works by exchanging encrypted security information between clients (which can be users or machines), the Kerberos authentication server, and the resource you are trying to access. The information that is initially exchanged when attempting to prove one's identity is known as a ticket. The information used to encrypt tickets and subsequent communications is known as a key. Once the identity of a client is verified, that client is granted a Kerberos token that can be used to verify its identity to any Kerberos-aware service. For security reasons, Kerberos tokens are time-stamped so that they automatically expire unless renewed by a user or service. The primary system for granting tickets (which houses the master copy of the Kerberos database) is known as the Kerberos Key Distribution Center (KDC).

The timestamps contained within Kerberos tokens (and tickets) can be verified only if the time and date are synchronized across Kerberos clients and servers. Kerberos authentication will fail if client and server clocks become skewed by more than five minutes. You should always run NTP (Network Time Protocol) daemons on all Kerberos clients and servers to guarantee that their clocks remain in sync [Hack #22] .

Kerberos uses the term realm to differentiate between authentication and Internet domains. A Kerberos realm is a set of machines that rely on a specific Kerberos server for authentication and therefore trust that server. In Kerberos configuration files, your realm is typically identified in uppercase characters in order to differentiate it from any similar DNS domain with which it is associated.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Authenticate NFS-Lovers with NIS

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you're using NFS, using its companion authentication mechanism may be the right way to go.

The Network Information System (NIS) is a distributed authentication mechanism that was originally developed by Sun Microsystems and is most commonly used in conjunction with the file-sharing protocol NFS [Hack #56] . NIS enables all of the machines in a computing environment to share access to a centralized collection of authentication-related files and service configuration information, known as "maps." Each NIS map is typically provided in several different ways, each organized to optimize a specific type of access to that information, such as lookups by name or by some unique numeric component (such as being able to access a group map by group ID, a host's map by address, and so on).

NIS+, also from Sun Microsystems, is the successor to NIS. Much like LDAP, it organizes information hierarchically. Unfortunately, NIS+ never really caught on outside of Sun systems, and therefore few Unix and Unix-like operating systems (such as, for example, Linux) bother to support NIS+.

Most Linux distributions provide packages that include NIS client and server software, but if yours doesn't, or you simply want to install the latest and greatest, you'll need to build and install the following packages from ftp://ftp.kernel.org/pub/linux/utils/net/NIS:

ypbind-mt

The client NIS daemon

ypserv

The NIS server

yp-tools

The standard NIS utilities for displaying NIS files, changing your NIS password, changing the full name or shell in your NIS password file entry, and querying various aspects of an NIS server or NIS maps

The names of these packages will also include version numbers and an extension based on the archive format that you download (gzip or bzip2).

As mentioned earlier, NIS is the most commonly used distributed authentication mechanism today, largely because it is shipped free with almost all Unix and Unix-like systems. Another reason for the prevalence of NIS is that it's incredibly easy to set up. This section walks you through the process of setting up an NIS server. Setting up an NIS client is explained in the next section.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Sync LDAP Data with NIS

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Run a script out of cron to help with a graceful transformation to LDAP.

An NIS-to-LDAP migration is a nontrivial event in any environment. If the switch were as simple as moving data from one place to another, most organizations would've done it by now. The reality in many production environments, large and small, is that some applications (and even appliances) do not yet support LDAP or don't support LDAP to the extent that we would like. Eventually, most places come to terms with LDAP's limitations and implement a "phase in" approach, which involves using LDAP where it is fully supported but keeping NIS around for those things that require it.

In those environments where the authentication source will be NIS for some legacy systems and LDAP for those newer systems that support it, the challenge becomes keeping the data synchronized between NIS and LDAP. Over the past couple of years, I have found several tools that attempt to solve this problem. One is a C program that, though it is amazingly generic, requires a whole bunch of flags that will look quite cryptic to some system administrators. Another solution consisted of a suite of tools that attempted to do too much and weren't very configurable. I was unable to make friends with these tools, as they seemed to make assumptions about my environment that would never be true.

In the end, I did find a Perl script online that had a very elementary structure that anyone could understand. It was clearly written and well commented, but unfortunately it wasn't actually written to complete the job it claimed to do. Rather than continuing my search, I broke down and decided that, by using this Perl script as a "good enough" skeleton, I could get it to work for my needs. Here is my Perl hack for taking data residing in LDAP and creating NIS maps.

	#!/usr/bin/perl
	use Net::LDAP;

	## CONFIG
	my $server = "ldap-server";
	my $base = "dc=example,dc=com";
	my $bind = "uid=ldap2nis,ou=People,dc=example,dc=com";
	my $bindpw = 'password';
	my $groupf = "group";
	my $passwf = "passwd";
	my $buildyp = "false";
	## CONNECT
	my $ldap = Net::LDAP->new($server, onerror => 'die' );
	$ldaps = $ldap->start_tls(verify=>'none') or die "Couldn't start tls: $@\n";
	$ldap->bind( dn => $bind, password => $bindpw) or die "Bind failed: $@\n";

	## PRINT PASSWORD FILE

	my $res = $ldap->search(
				base => $base,
				scope => 'sub', # entire tree
				timelimit => 600,
				filter => '(&(objectClass=posixAccount))',
				attrs => ['uid', 'uidNumber', 'gidNumber', 'gecos',
	'homeDirectory', 'loginShell', 'userPassword'],
	);

	open(PASSWORD, ">$passwf");
	while (my $entry = $res->shift_entry) {
		  (my $uid = $entry->get_value('uid')) =~ s/:/./g;
		  (my $uidnum = $entry->get_value('uidNumber')) =~ s/:/./g;
		  (my $gidnum = $entry->get_value('gidNumber')) =~ s/:/./g;
		  (my $gecos = $entry->get_value('gecos')) =~ s/:/./g;
		  (my $homedir = $entry->get_value('homeDirectory')) =~ s/:/./g;
		  (my $shell = $entry->get_value('loginShell')) =~ s/:/./g;
		  (my $up = $entry->get_value('userPassword')) =~ s/:/./g;
		  if (index($up, "{crypt}") != -1) {
			  $up = substr($up, 7);
		  }else{
		  	  $up = crypt($up, "bR"); 
		  } 
		  $passrecord = join(':',$uid,$up,$uidnum,$gidnum,$gecos,$homedir,$shell); 
		  print PASSWORD "$passrecord\n";
	}
	close(PASSWORD);
	chmod(0600, $passwf);

	## PRINT GROUP FILE
	my $res = $ldap->search(
		base => $base,
		scope => 'sub', # entire tree
		timelimit => 600,
		filter => '(&(objectClass=posixGroup))',
		attrs => ['cn', 'gidNumber', 'memberuid'],
		
	);

	open(GROUP, ">$groupf");
	while (my $entry = $res->shift_entry) {
	(my $grname = $entry->get_value('cn')) =~ s/:/./g;
	my $grpass = "*";
	(my $grnum = $entry->get_value('gidNumber')) =~ s/:/./g;
	(@members = $entry->get_value('memberuid')) =~ s/:/./g;
	
	if($#members >= 0) {
		$memusers = join(',',@members);
	}else{
		$memusers = "";
	}
	
	$grprecord = join(':', $grname,$grpass,$grnum,$memusers);
	print GROUP "$grprecord\n";
  }
  close(GROUP);
  chmod(0600, $groupf);

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Remote GUI Connectivity

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Networks are the backbone of most computing today. Even small businesses depend on internal networks of desktop computers and servers to deliver services such as email, file and directory sharing, access to internal and external web servers, and so on. For the system administrator, this means that you typically need to connect to different types of systems during the course of a day to perform different types of administrative tasks.

If your network is composed solely of Linux systems, you can use standard command-line tools such as ssh or telnet to connect to remote systems and get most of your work done, but let's face it—it's a graphical world nowadays. There are lots of great administrative tools out there that make it easier to do complex tasks that could easily be derailed by a typo in a long command line. And if you also administer Microsoft Windows or Mac OS X systems, you'll need access to graphical tools that run on those systems, too.

This chapter primarily consists of hacks that make it easy to establish graphical connections to remote machines from a desktop system, enabling people to run graphical packages that are installed on those remote systems without leaving their chairs. It also provides a hack that tells you how to use Webmin, a centralized, web-based system administration utility that enables you to access multiple server resources from a single system and browser.

The hacks in this chapter aren't just for system administrators: they're for anyone who needs to use graphical interfaces on multiple machines. Even if yours is a Linux shop, chances are that your users will occasionally need access to Windows machines to update project plans, requirements documents, spreadsheets, and so on. You could give everyone a Windows system "just in case," but that isn't reasonable or cost-effective. Instead, why not just allow users to connect to a remote Windows system or Windows Terminal server on those rare occasions when Windows software is actually necessary? Similarly, if people need to check their personal email while they're at work, you could configure their mail clients to support additional mail profiles, leave the mail on the server, enter personal passwords, and so on. Many businesses don't mind this sort of thing, but people may (and should) object to having copies of personal mail and authentication information on machines that aren't theirs. Using hacks such as "Access Systems Remotely with VNC"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Hacks 10–19: Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Networks are the backbone of most computing today. Even small businesses depend on internal networks of desktop computers and servers to deliver services such as email, file and directory sharing, access to internal and external web servers, and so on. For the system administrator, this means that you typically need to connect to different types of systems during the course of a day to perform different types of administrative tasks.

If your network is composed solely of Linux systems, you can use standard command-line tools such as ssh or telnet to connect to remote systems and get most of your work done, but let's face it—it's a graphical world nowadays. There are lots of great administrative tools out there that make it easier to do complex tasks that could easily be derailed by a typo in a long command line. And if you also administer Microsoft Windows or Mac OS X systems, you'll need access to graphical tools that run on those systems, too.

This chapter primarily consists of hacks that make it easy to establish graphical connections to remote machines from a desktop system, enabling people to run graphical packages that are installed on those remote systems without leaving their chairs. It also provides a hack that tells you how to use Webmin, a centralized, web-based system administration utility that enables you to access multiple server resources from a single system and browser.

The hacks in this chapter aren't just for system administrators: they're for anyone who needs to use graphical interfaces on multiple machines. Even if yours is a Linux shop, chances are that your users will occasionally need access to Windows machines to update project plans, requirements documents, spreadsheets, and so on. You could give everyone a Windows system "just in case," but that isn't reasonable or cost-effective. Instead, why not just allow users to connect to a remote Windows system or Windows Terminal server on those rare occasions when Windows software is actually necessary? Similarly, if people need to check their personal email while they're at work, you could configure their mail clients to support additional mail profiles, leave the mail on the server, enter personal passwords, and so on. Many businesses don't mind this sort of thing, but people may (and should) object to having copies of personal mail and authentication information on machines that aren't theirs. Using hacks such as "Access Systems Remotely with VNC"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Access Systems Remotely with VNC

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Virtual Network Computing is the next best thing to being there—and it's cross-platform, too.

Command-line-oriented utilities (such as ssh and telnet) for accessing remote systems are fine for many things, but they don't help much when you need to run graphical utilities on a remote system. You can play around with the standard X Window System DISPLAY environment variable to output programs to different displays, or you can take advantage of cooler, newer technologies such as VNC to display the entire desktop of a remote system in a window on the system on which you're currently working. This hack explains how to use VNC to do just that. VNC is a cross-platform thin client technology originally developed by Olivetti Research Labs in Cambridge, England, who were later acquired by AT&T. A VNC server runs on a desktop or server system and exports an X Window System desktop that can be accessed by a VNC client running on another system. VNC servers are typically password-protected and maintain their state across accesses from different clients. This makes VNC an optimal environment for accessing a graphical console and running graphical administrative and monitoring applications remotely.

Any host system can run multiple VNC servers, each of which exports a separate desktop environment and therefore maintains separate state. Similarly, multiple clients can connect to and interact with the same VNC server, providing an excellent environment for training, since many users can view the same desktop.

VNC follows the traditional client/server model rather than the X Window System client/server model. A VNC server is actually an X Window System process that exports an X desktop from the system on which it is running, using a virtual framebuffer to maintain state information about the graphical applications running within that server. VNC uses its own Remote Frame Buffer (RFB) protocol to export graphical changes and handle mouse and keyboard events. Though VNC exports a graphical environment, the RFB protocol is highly optimized, minimizing the amount of screen update information that must be passed between client and server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Access VNC Servers over the Web

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With a little extra software, you can access your VNC servers in any web browser.

If you use VNC often enough, you'll eventually find yourself needing access to a VNC viewer from a computer on which it has not been installed. You can put a copy of the installer or the installed application on a public share, but manually connecting each time is a pain, especially if you just need to quickly type a command or check status on the remote machine running your VNC server—and always carrying a CD or floppy with the VNC viewer application on it is equally irksome.

Fortunately, the people who designed VNC are smart folks, and they thought of a solution to the roaming user problem—a hassle-free way to make your VNC servers available even if the system you're using doesn't have VNC client software installed. All VNC servers include a small built-in web server that can serve the Java classes needed for any Java-enabled browser to connect to the VNC server. This lets you access any VNC session that is already running on one of your systems using any modern, Java-enabled browser. The VNC server listens for HTTP connections on port 5800 plus the number of the display being exported. Therefore, to view a VNC session running on display 1 of the host 64bit.vonhagen.org, you would access the URL http://64bit.vonhagen.org:5801/.

As with any VNC session, the Java classes that implement the VNC client will prompt you for the VNC server's password before connecting to the VNC server. Figure 2-3 shows a connection to my laptop's VNC server, on which I am running the Fluxbox window manager (http://fluxbox.sourceforge.net).

Figure 2-3: A VNC desktop in the Firefox web browser

To enable web access to your VNC server(s), you must install the Java class and JAR files, and a few additional files for the HTTP VNC server on the system where you'll be running it. These files are installed as part of both the RealVNC and TightVNC server packages, but they can also be obtained from the RealVNC and TightVNC web sites (http://www.realvnc.com and http://www.tightvnc.com

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Secure VNC via SSH

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Easily encrypt your remote connections by setting up a secure tunnel.

VNC is a great way of getting access to a graphical desktop on a remote system. However, once you're connected, VNC uses standard TCP/IP for all traffic between the local viewer and the remote server. Anyone with a packet sniffer on your local network can grab packets and monitor your traffic, which is a bad thing if you're using the remote session for administrative tasks that will transmit passwords.

Luckily, it's quite easy to leverage the encryption provided by SSH, the Secure Shell, in your VNC sessions. You do this by setting up an SSH tunnel, which is essentially just a mapping between local and remote ports so that all traffic to a specified port on a remote machine is forwarded via SSH to a port on your local machine. This hack explains how to combine the power of VNC with the security of SSH to provide secure connections to remote machines. For general information about SSH, see the first volume of Linux Server Hacks by Rob Flickenger (O'Reilly), which devotes an entire chapter to SSH.

In addition to the standard secure shell functionality that most people use SSH for, SSH also enables you to forward traffic from a specific port on a remote machine to a specific port on your local machine. Doing this requires that a VNC server is already running on the remote machine, and that you establish a standard SSH connection to the remote machine but supply the –L (local) option and an appropriate argument when you execute the ssh command.

The syntax for forwarding ports when using a standard SSH connection is the following:

	$ ssh -L local-port:local-host:remote-port remote-host

As discussed in "Access Systems Remotely with VNC" [Hack #10] , standard VNC traffic with a given host takes place over port 590x, where x is the X Window System display that a specific VNC server is using. For example, to use SSH to forward VNC traffic from the VNC server running on the X Window System display:1 of the host nld.vonhagen.org to the same port on your local system,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Autostart VNC Servers on Demand

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Eliminate the need to manually start VNC servers on remote machines.

In this age of enlightenment and whizzy graphical devices, most Unix servers have graphical consoles instead of the VT100s or LA123s of days gone by. This is certainly true of most Linux servers, though most machine rooms save space by installing a single monitor and using a KVM to switch between the systems that are actually using it at the moment. As explained in "Access Systems Remotely with VNC" [Hack #10] , the traditional mode of operation for VNC is to SSH/telnet/whatever to a remote system, manually start a VNC server, and then nip back to the system you're actually using and start the VNC viewer there. It's easy enough—but isn't the whole "SSH there, stand on one leg, start this, pop back here, start that here" business irritating?

This hack explains how to avoid all that by integrating the VNC X Window System server directly into your graphical X Window System login environment. The basic idea is that you configure your machine to use your system's Internet daemon ( xinetd or inetd) to start the Xvnc server whenever an incoming VNC connection is sensed on one or more ports. You also configure your system to use the X Display Manager Control Protocol (XDMCP) to manage any new X displays, such as the Xvnc server. When the Xvnc server starts in response to an incoming port request, it displays an XDMCP login screen, you log in, and voilà!

The modern Linux Internet daemon xinetd (like its predecessor inetd, which may still be used somewhere) initiates the daemons associated with various servers in response to incoming requests on different ports, as defined in the file /etc/services. Throughout the rest of this hack, I'll refer to xinetd and inetd together as x/inetd, using their specific names whenever necessary to differentiate between them.

The x/inetd daemon is often referred to as a "super server," because its job is to manage other server processes. Using x/inetd lowers the load on your systems, because the daemons for these services don't have to be running all the time—

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Put Your Desktops on a Thin Client Diet

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Centralize administration by using the Linux Terminal Server Project and existing or inexpensive desktop systems to give your users the computing power they need at a price you can afford.

Though the cost of hardware is constantly decreasing, it is still greater than zero. Putting a high-powered workstation on everyone's desk is a nice idea, but not everyone needs a dual-processor Mac or Linux box to get their work done. The key requirement for most users is access to the applications and data they're working on and enough memory to work with them.

The Linux Terminal Server Project (LTSP; http://www.ltsp.org) lets you boot desktop systems from a remote server, gives users access to their applications and data when they log in, and provides a graphical, X Window System working environment that is functionally identical to booting from a local disk. This can provide substantial cost savings by enabling you to deploy or reuse less-expensive hardware on your users' desktops, since it reduces the amount of local storage and other hardware that any desktop system requires. A processor that is too slow to keep up with the demands of today's applications can still function quite nicely when its sole function is to update a display and respond to mouse and keyboard input.

Centralizing system resources on high-powered servers also provides substantial benefits to system administrators by eliminating the need to individually maintain and upgrade desktop operating systems and application software. All the software that a desktop system requires beyond a boot floppy or network boot information is stored on the server.

The LTSP also provides a great alternative to deploying and maintaining dual-boot systems throughout your enterprise or installing X Window System software on every Windows box if users only need to run Linux software occasionally. Give the users LTSP boot disks configured for their desktop systems and have them reboot using these disks. Problem solved! They have Linux systems on their desktops until they reboot.

Version 4.1 of the LTSP was the latest version at the time this book was written. Installation, configuration, and conceptual information should be similar for any newer version that may exist by the time that you read this.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Run Windows over the Network

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Stop deploying Windows systems and software for people who only need occasional access to a few applications.

Regardless of how you feel about Microsoft, you can't escape the Windows operating system and the applications that require it. Even companies that live on Linux for development and testing still need to provide developers with access to Windows systems so that they can share various types of documents with management in formats that management can understand. This quickly gets expensive, and it's generally a hassle for the system administrators who have to deploy and manage these machines, set up the Windows shares de jour on each computer or in user profiles, install the right software packages, and so on.

Many companies take a first stab at saving money by putting two computers under many desks, and sharing a monitor, keyboard, and mouse between them using a KVM switch. That's fine, except that your company pays for the extra systems, Windows licenses, and KVM switches and has to deal with the administrative and security hassles inherent in deploying two desktops per user. As an alternative, some companies use the open source WINE project or its commercial variant Crossover Office (which is a great package, by the way), to run Windows applications natively on Linux machines.

If you need to give users occasional access to Windows-only applications but want to minimize costs and administrative hassles, a good solution is to install Windows Terminal Services on a reasonably beefy Windows system and purchase a pool of Client Access Licenses that are assigned to the users who need to be able to use the applications. Remote clients can then attach to the Terminal Services server and run virtual Windows sessions in windows on their desktops. Install the software that people need to use on the Terminal Services server or in shares defined in your user profiles, and any remote users connected to the server will be able to run the software they need. Luckily, access to Windows Terminal Services doesn't even require a Windows system anymore—Linux users, including those working in an LTSP environment

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Secure, Lightweight X Connections with FreeNX

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The standard X Window System is very network-intensive. FreeNX compresses and optimizes X communications and is ideally suited for slow connections such as dialups.

FreeNX is a free, GPL implementation of NoMachine's NX Server (http://www.nomachine.com). NoMachine has developed a compression technology that substantially reduces the size of X Window System communications and adds other performance improvements through caching and general protocol optimization. NoMachine provides several informative white papers about their technology and its performance at http://www.nomachine.com/documentation.php. If you're already a VNC fan, NX is definitely worth a look, for performance reasons as well as for the fact that it inherently uses SSH for secure communications between client and server.

The free and commercial versions of the NX server differ in terms of capabilities (and, of course, cost). FreeNX provides all of the core capabilities of the commercial NX server for remote connection, but it does not currently include the SMB and printing (CUPS) support provided by the commercial NX server. At the moment, commercial server licenses for NoMachine's personal edition cost around 55 euros, which is cheap. They also offer small business and enterprise licenses, which you may be interested in if you want to have product support, get updates, and get SMB and CUPS support now, rather than waiting for them to appear and mature in FreeNX. Personally, though I use FreeNX, I bought a server license because it seemed like the right thing to do. I use the free NoMachine client everywhere, and I also feel that the NoMachine folks deserve my support for having come up with a great technology and released it as open source.

This hack explains how to install and configure the open source versions of NoMachine's NX server, the FreeNX package, and the free commercial NX client from NoMachine.

The FreeNX server consists of two packages: the nx package, which consists of binaries and libraries compiled from the open source packages from NoMachine; and the freenx

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Secure VNC Connections with FreeNX

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

FreeNX isn't just for the X Window System—it can also provide secure VNC connections.

If "Secure, Lightweight X Connections with FreeNX" [Hack #16] got you excited about the performance and possibilities of the FreeNX server for displaying X Window System desktops over slow connections, just wait— there's more! FreeNX also supports translating the protocols used by VNC into X Window System protocols that it can then exchange with a standard NX client. If you install an NX client (such as NoMachine's excellent nxclient) on your desktop system, you can use a single application to both communicate with remote X Window sessions on your NX server and also proxy through to any VNC server that you can access from the NX server. The VNC server does not have to be running on the same system as the NX server—the NX server just needs to be able to contact it over the network.

Communications between the VNC server and the NX server are not encrypted, but communications between your NX client and the NX server are. This can be especially useful if you are working remotely and want to access a VNC server inside your company's network, but you need any communication taking place over the public Internet to be secure. Your corporate firewall already supports SSH, so you don't even need to open any other ports to support VNC.

The previous hack explained how to obtain and install NoMachine's excellent NX client. To create a configuration for accessing VNC through your NX client, click the Unix drop-down shown in Figure 2-17, and select VNC. The dialog shown in Figure 2-20 will display.

Figure 2-20: VNC configuration in NX Client

In this dialog, specify the hostname or IP address of the system on which your VNC server is running, and the port on which it is running. By default, the port will be 5900 plus the number of the display that the VNC server is using. For example, if the VNC server was running on display:1 on the remote system, you would enter 5901 as the port number.

Next, specify the password for the remote VNC server, and check the "Remember my password" checkbox if you want to make this a permanent part of your configuration. Click OK to close this dialog, proceed with your standard NX client configuration and save your NX/VNC configuration.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Secure Windows Terminal Connections with FreeNX

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

FreeNX isn't just for the X Window System and VNC—it can also provide secure Windows Terminal Services connections.

If "Secure, Lightweight X Connections with FreeNX" [Hack #16] and "Secure VNC Connections with FreeNX" [Hack #17] got you excited about the performance and possibilities of the FreeNX server for displaying X Window System and VNC desktops over slow connections, get ready because FreeNX has even more tricks up its sleeve. FreeNX also supports translating the Remote Desktop Protocol (RDP) used by Windows Terminal Services into X Window System protocols that it can then exchange with a standard NX client. If you install an NX client system (such as NoMachine's excellent nxclient) on your desktop, you can use a single application to communicate with remote X Window sessions on your NX server, proxy through to any VNC server you can access from the NX server or proxy through to any Windows Terminal server you can access from the NX server. Like the VNC server, the Windows Terminal server does not have to be running on the same system as the NX server— which is just as well, because the NX server used by both FreeNX and NoMachine's NX runs only on Unix and Linux boxes!

Like VNC through FreeNX, communications between the Windows Terminal server and the NX server are not encrypted, but communications between your NX client and the NX server are. This can be especially useful if you are working remotely and want to access a Windows Terminal server inside your company's network, but you need any communication taking place over the public Internet to be secure. Your corporate firewall already supports SSH, so you don't even need to open any other ports to support the Windows Terminal server.

"Secure VNC Connections with FreeNX" [Hack #17] explained how to obtain and install NoMachine's excellent NX client. To create a configuration for accessing a Windows Terminal server through your NX client, click the Unix drop-down shown in previously in Figure 2-17, and select RDP. The dialog shown in Figure 2-22 will display.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Remote Administration with Webmin

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Webmin provides secure access to logfiles, system statistics, and many common administration tasks, all from your favorite web browser.

Administering a system can be a tough job. With user accounts to create, services to configure, logs to check, and all the other duties system administrators face, it can become quite a load. Thankfully, there's some software out there that can help make life easier for the weary sysadmin. One of these pieces of software is called Webmin. Webmin allows you to control a large portion of the functionality of your server from an easy-to-use web interface. Most major services are covered, including Apache, BIND, SSH, LDAP, Samba, WU-FTP, Sendmail, MySQL, and many others.

Figure 2-23: A Windows Terminal server connection in nxclient

Installation of Webmin couldn't be easier. If you're running an RPM-based distribution such as SUSE or Fedora Core, simply grab the latest version from the Webmin home page at http://www.webmin.com. Install Webmin with the following command, where version-number is the version that you downloaded:

	# rpm –install Webmin-version-number.rpm

If you're using a non-RPM-based distribution such as Debian or Slackware, you can install from source. Simply download the latest tarball from http://www.webmin.com and unpack it to your system as usual. Navigate into the newly created Webmin directory, and execute the following command as root:

	# ./setup.sh /usr/local/Webmin

This will start the setup process for Webmin. The script will ask you for a number of options. For most of these questions, the default answers should suffice. However, there are a few answers that should be changed for security reasons. For instance, it is widely known that the default port for Webmin is 10000, so when the script asks you what port to run it on, pick something original—just make sure that you pick something above port 1024, because port numbers lower than that are typically reserved for system services. I typically use port 5555. Changing the default port helps protect against automated tools probing Webmin and discovering your Webmin login by checking its default port.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: System Services

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter