Archive for the ‘software’ Category

When Your Naming Scheme Runs Dry

August 6, 2008

The group of system administrators I worked with for over a decade had a tradition of giving Unix computers host names that followed a different theme for each cluster of computers.

We started out as students running the computer labs for the College of Engineering at the University of Maryland, College Park in the late 1980s. Our first public computer lab was a dozen or so Sun 3/50 and 3/60 workstations named after Tolkien’s The Hobbit. Host names included shire, bilbo, gloin, rivendell, etc.

When the Sun 3’s became obsolete, we turned them into X terminals connecting to several Sparcstation servers, which got their own naming scheme: coke, pepsi, jolt, and mountain-dew. We could have kept adding soda names for awhile, but we didn’t need many servers for that lab.

In the staff office (the “Hackers Pitt”, with spelling from Buckaroo Banzai), the Sparcstations we got for testing and software development were called tweak, twiddle, and frob. Good thing we didn’t need to come up with any more names in that series!

Here are a couple of pictures of the Hackers Pitt. Dave, Josh, and Chris:

Kurt, Dave, and Randall:

Later, we opened up another lab, consisting of Decstations, I think. We decided to go with names of computer languages as the naming scheme, so we had workstations called basic, cobol, lisp, perl, etc. There was a networked Postscript laser printer in the lab, and someone got the bright idea to give it a name in the same scheme, so naturally it had to be called postscript! A few months later, though, we had to rename it, because some software would get confused and malfunction when encountering a printer queue called postscript.

Aerospace Engineering named their computers after airplanes. Their Sun3 server was called hellcat, a WWII fighter.

There was one department in the College of Engineering that simply numbered their workstations: Chemical Engineering, whose computers were named cm##. The student sysadmins didn’t like that scheme much, because it was hard to keep those computers straight. Their names had no memorable personalities, so we had trouble remembering whether we were supposed to do something to cm18 or cm19, or cm23 or cm32.

Within a couple of years, many of us started work at UUNET and created one of the first commercial web hosting services. We took our penchant for naming schemes with us. Here’s a picture of Josh, Chris, and Kurt in Kurt’s office at UUNET assembling some servers:

The infrastructure servers (email, rdist, backups, etc.) had names of butlers from literature: jeeves, nestor, smithers, alfred. That was a clever but very restrictive scheme. It turns out there aren’t very many well-known butlers in literature. Now there’s a Wikipedia article listing them, but at the time we were beating our heads against the wall trying to think of more.

For Kerberos (secure login) servers, the list was the most limited. The first one was called keymaster (from Ghostbusters). When we added a second one as a backup, we had to make up a name. Would it be keyslave or keyminor? Hmm, maybe that wasn’t such a great idea.

For customer web servers, we decided on a larger class of cleverly appropriate names: spider names. The first few were easy: charlotte, blackwidow, brownrecluse, tarantula, trapdoor, funnelweb. After exhausting the well-known ones, we had to get more creative or obscure: peterparker, banana, garden, huntsman, crab. Customers had to login or FTP to the machine’s name to administer their servers, and it felt a little silly to tell them their web server was hosted on, say, banana. Who actually knows there’s such a thing as a banana spider? As we got more customers, we wasted quite a bit of time researching and compiling lists of spider species so we’d have enough names for new servers we were bringing online.

It all started out as good fun, but these days I’d just call them all web001, web002, mail, etc. and be done with it. No creative naming scheme will scale to hundreds of computers.

I confess that at home, I adopted a naming scheme based on classical elements: fire, water, air, earth, and a few more inspired by that pattern. I haven’t changed it partly because the limitations of that scheme help motivate me to not keep too many computers at home.

Introduction To Kerberos

August 5, 2008

(Written in June, 2000)

What Is Kerberos?

This is an introduction to the concepts and conventions used in Kerberos. It is intended to give system administrators and software developers an overview of how Kerberos works. It does not contain step by step, detailed instructions on setting up or using Kerberos.

For more information on Kerberos, see its home page at
http://web.mit.edu/kerberos/www/
and Microsoft’s Windows 2000 Kerberos page at
http://technet.microsoft.com/en-us/windowsserver/2000/bb742431.aspx

Kerberos is a software package providing authentication between clients (typically run interactively by people) and servers (such as a telnet or POP mail daemon). It consists of several C libraries, several standard client and server programs, a database, and some configuration files. Programs that are not part of the Kerberos software distribution can be Kerberos-enabled by adding calls to the Kerberos libraries.

Kerberos was developed at MIT as part of Project Athena. It is named after the three-headed dog who guarded the entrance to Hades in Greek mythology (called Cerberus by the Romans). The C API is called the General Security Service (GSSAPI). The current version of Kerberos is v5, though v4 is still in widespread use. v5 and v4 are not directly compatible, but v5 has a v4 compatibility mode. This document discusses only v5, as v4 is being phased out.

What techniques does it use?

Kerberos uses private keys (a.k.a. secret keys) to provide authentication. This is unlike SSH, which uses public-private key pairs. In Kerberos, each client has its own private key (your password) and each server also has its own private key (which is stored in a file called a keytab on that server host). Automated clients (such as cron jobs) also have private keys stored in keytabs. Kerberos private keys are never sent over the network in cleartext (that’s what keeps them private). Kerberos does not depend on IP addresses or DNS names for providing authentication, so if they are spoofed, connections will not succeed.

Kerberos divides the world into administrative realms, with names based on hosts’ DNS domain names but in all capital letters. In each realm is a physically secure host with a database containing the private keys of all clients and servers in that realm. That way, each organization can control its own private keys. The host with this database is a trusted third party. It is running a Kerberos server, and is called the Key Distribution Center, or KDC. The KDC database can be replicated onto other hosts for redundancy. (Kerberos calls this propagation.) The host with the master copy is called the primary KDC, and the hosts with the copies are called secondary KDCs.

A client might actually have several private keys, for authenticating to different services. For example, a person might have one private key for logging in as themself, and another private key for logging in as the superuser (root). To figure out which of a client’s private keys to use when authenticating to a server, each private key is labeled with an principal name, which is their user name with an optional instance name. The default instance for a user is empty and is used for logging in, and the principal name looks like “username@REALMNAME” (similar to an email address). The other principal names look like “username/instancename@REALMNAME”, for example, “djm/root@VA.PUBNIX.COM”. (Although any number of instance names separated by slashes can be used, in practice only one level of instance names is ever used.) The “@REALMNAME” is optional, and defaults to the realm of the local host.

Servers’ private keys are also labeled by principal names, with the same format except the user name is replaced by the service name. They look like “servicename/hostname@REALMNAME”, for example, “imap/jenkins.web.us.uu.net@VA.PUBNIX.COM”. For logins, the service name is “host”.

You can see from the previous example that each Kerberos realm can authenticate for servers in multiple DNS domains. But each DNS domain can be served by only one Kerberos realm. However, clients can authenticate to servers in any realm in which they have principals.

Each request for authentication to the Kerberos server sends the client a sesssion key, which the client caches in a credentials cache file locally. The session keys are used to encrypt connections to servers instead of using the client’s private keys. Session keys are valid only for a few hours, to prevent replay attacks.

The authenticated information for a connection between a particular client and server is called a ticket. A client’s tickets are stored in the credentials cache along with the session key. The first ticket which is issued to a client, and can be decrypted using that client’s private key, is called a ticket-granting ticket, or TGT. It is used for authenticating all services, instead of using the client’s private key, to avoid having to type your password every time you check your email or login to another host.

After an authenticated connection to a server is established, whatever protocol that server uses can either pass information in cleartext, or encrypt it in the session key, as desired. For example, Kerberos “rcp” copies files in cleartext unless the “-x” option is given.

How Is It Configured?

Every host using Kerberos needs a copy of the master configuration file, called “krb5.conf” on Unix, and usually located in /etc or /etc/krb5. The main functions of this file are to specify the KDC(s) for each realm, which DNS domains each realm services, and some optional parameters. There is no distributed lookup service (analogous to DNS) for Kerberos realms. You need to create or copy a krb5.conf that contains information about the realms that you want to access servers in.

In addition, the KDC has a “kdc.conf” giving some parameters and file locations, and ACL files for Kerberos administration and database replication.

On Unix, entries in “/etc/inetd.conf” for the standard versions of servers such as “telnetd” and “rshd” are replaced with entries for the Kerberos versions.

Semi-standard locations for the Kerberos programs and libraries on Unix are /usr/krb5 or /usr/local/krb5.

How Is It Administrated?

Kerberos administration consists mostly of creating principals for new clients and servers, deleting principals for retired clients and servers, creating keytabs for servers and automated clients, and changing passwords.

After the initial setup, most Kerberos administration is done with the “kadmin” program, which uses a separate protocol to connect to a Kerberos administration server on the primary KDC for a realm. Administrative connections can not be made to the secondary KDCs. kadmin uses an “admin” instance to authenticate Kerberos system administrators. There is another version of it called “kadmin.local” that runs only on the primary KDC and does not require a password.

Any client can change their own Kerberos passwords using the “kpasswd” program. Note that the kpasswd protocol changed between Kerberos v5 release 1.0 and release 1.1.

How Does It Authenticate?

As mentioned above, Kerberos uses a trusted third party model. Authentication is initiated by a client, which contacts the KDC to get a TGT, which it decrypts using its own private key. The client then uses the TGT to get a ticket for a particular server from the KDC, and then connects to that server. This process is illustrated in the accompanying diagram (click to enlarge).

Kerberos authentication

More concretely, a user runs “kinit”, which prompts for a password, to get a TGT. Alternately, some login programs and graphical telnet clients get a TGT with the password provided, as does the Kerberos “su” program, “ksu”. kinit can get a private key from a keytab instead of prompting for a password, for use with automated clients.

You can list your current credentials (tickets and session keys) using “klist” and remove them (when you log out) using “kdestroy”.

For remote logins, there is an optional file similar to the non-Kerberos “.rhosts” file, called “.k5login”, which a user can create in their home directory. This file lists principals who are allowed to login
as that user from other hosts using Kerberos, or “ksu” to that user on that host.

A Pragmatic Decision

August 5, 2008

(The following appears in the March 1988 UNIX Review magazine, in a comparative review of C compilers. The version of gcc that they tested in the article was 1.17, but you can still find the code they mention in gcc 1.40, in cccp.c.)

GCC’s early handling of the ANSI #pragma construct is perhaps worth noting at this point. Compiler writers are at liberty to deal with #pragma as they see fit. Paul Rubin, in a bit of whimsy, chose to start running the Tower-of-Hanoi game under emacs. Where this was impossible, a session of the hack game was attempted. Failing that, a rogue session was attempted. When all of these efforts failed, the compiler printed the error message: “You are in a maze of twisty compiler features, all different”.

More recent versions of GCC have this code disabled, however, and #pragma directives now are simply ignored. The original code is still distributed, though, for those who prefer it.


Create your own website, free on WordPress.com.Create your own website.
Start free