Remote Password Update
David Collier-Brown If you have more than one machine, it can be a nuisance to change your password in several places. If you have more than two or three machines and multiple users, updating the password on each machine individually is error-prone. Fixing people's passwords, even your own, wastes time better spent doing more useful work. A program that allows you to change the password once on a server then have all the client machines updated from it would be more efficient. This article introduces a remote password update program that Iuse to steamline these tasks. Alternatives There are lots of ways to update password files for several machines, including sneakernet. Most are rather complicated. One (kerberos) requires you to dedicate a machine just to the management of passwords and "tickets." Another (YP) assumes that every machine you have will store all the main configuration tables under the control of a single program. This is not the simple, single, elegant solution I normally expect to see on UNIX. So, several years ago, I set out to provide a simple mechanism that used only rather pedestrian UNIX networking facilities (rlogin and rsh). The homebrew program here, called "Blue Pages" was originally written to allow me to avoid using Yellow Pages in a university teaching lab. Besides being insecure, YP in that era was appallingly slow when an entire class attempted to change passwords. Since then, I've rewritten the program three times and found that the approach works as well for three machines at home as it does for a 40-machine commercial R&D company. And, it works on machines that can't run YP. There are only two parts to the program: the first arranges for everyone to change their passwords on a "master" server, and the second arranges for the other machines to pick up the updated password file. The first uses rlogin, the second rsh, nfs, or ftp. The First Part Arranging for everyone to change their password on the master server appears deceptively simple: all they need to do is run the passwd program on the master. In fact, this is the hard part, and took several experiments before I found that I really didn't need anything more than rlogin and /bin/passwd. I was greatly relieved, as I lacked the time to write a massive program like YP or kerberos/hesiod. To change a password, you run the passwd command on your machine (a client). passwd is nothing more than a shell script that uses rlogin to connect you to a particular account on the master machine. That account has as its shell a program that prompts you for your old password, validates it, and then executes the regular passwd program. On the Client The script mentioned above passes your username as the TERM variable to the shell of the passwdd account on the master. And that's all the client needs do, other than produce messages (see Listing 1). On the Server The master has a special account, in this case called passwdd, which has as its shell the password-changing program. The account is special only in that its uid and gid match those of /bin/passwd. If you don't wish to have a root account, you can optionally make the passwdd program setuid (see the security section below).
passwdd::0:10:The Password-Changing Account:/:/etc/passwdd
This program (/etc/passwdd) gets the username from the TERM variable, which rlogin has passed us from the client. It asks for the user's old password, and if correct, executes /bin/passwd <user>. This program is completely unprivileged, but is run as root, so it inherits the normal (minimalistic) root environment. This allows it to execute /bin/passwd with a username, and have /bin/passwd prompt for the new password. In pseudocode, this is:
user=getenv(TERM)
if (encrypt(getpass()) == getpwent(user)->pw_passwd)
system("/bin/passwd user")
else
printf("Sorry.")
fi
The real code is in "The Server passwdd Program" (see Listing 2). So far, you've run one script, rlogin, and two other programs, all just to prompt for a new password. To make the process a little clearer, see the protocol diagram in Figure 1. The Second Part Now, you have to get the updated password file to the clients. This looks harder, but is actually much easier: cron can use any of at least five perfectly good ways. Alternatives There are two main sets of programs that can be used to transfer the files: the Berkeley r-commands and NFS. ftp and tftp are possible, but may pose security problems. Of these: Using the Berkeley r-commands:
Using NFS:
Using ftp:
Using tftp:
In all these cases, the file is deposited in a "safe" place (a partition with lots of space), and then a script copies it to /etc/passwd with suitable safety checks. The script could be as simple as:
if [ ! -f /etc/ptmp ]; then cp /some/safe/place/in/root /etc/ptmp mv /etc/ptmp /etc/passwd fi
That's almost what I've done, but without the race condition. The code is in "The Client Password Update Script" (see Listing 3). Note that it is somewhat harder if the machines are too different, because that requires you to decompose the password file into the root password, system-specific passwords, and common passwords, and then reassemble a password file with system-specific entries on the client. In this case, the password for root might be any of the following:
In other words, you can adapt the program to multiple groups of machines, each with its own systems administrators. All of those decisions can be made in the script that puts the password file together on the client machine, and it only adds a few lines to the example script. At this point, you're done; password changes start with an announcement that they're occuring on a different machine and end with a message about when they will be universally available. Everything else occurs quietly in the background. Portability This program works for Sun (SunOS 3, 4, and 5), HP-UX (8, 9, and 10 on series 700 and 800), BSD 4.3, IBM RS/6000, Linux, SCO, SGI Irix, MIPS RiscOS, DEC Ultrix, and all but one version of System V (the aforementioned ursus horribilis). If the client machine is running shadow passwords (as is common with SCO), you need to run /etc/pwconv to install the updated passwords into the shadow file. If the server is running shadow passwords, you need to extract the actual password fields from the shadow file and create an old-style password file to ship to the clients. Of course, if all your machines are using shadow passwords, you merely need to ship both files. Getting rsh and rcp to work is usually the big portability problem: some vendors want full domain names in .rhosts files, and some want just host names, and so on. But Is It Secure? Security raises its ugly head in two areas here: security on the server, and security for the transport channel. On the server, you are faced with providing an unpassworded privileged account or an unpassworded privileged program. This sounds horrible, but in fact, the security of the combination of programs is exactly as good as the security of /bin/passwd. The added programs merely authenticate a person and then run /bin/passwd. It is easy enough to read the program below and convince yourself that it does no more than it claims. It is harder to read /bin/passwd, for which you may or may not have the source. There is one extra risk to setuid-root programs. Because they usually start out running from the users's account, they need to be very careful about setting their $PATH, their shared library search path, and so on. In our case, we always run out of an account under control of the systems administrator, so we merely need to make the environment the same as root's. For that reason, passwdd is the account's shell, with a very minimal environment. Network Security You should be aware of two broad problems in network security: snooping on the net and trusting the wrong server. Snooping is a problem in any site that allows arbitrary users to collect packets. This system, as discussed so far, can allow someone to capture all the keystrokes of a user changing his/her password. This is as bad as someone snooping a telnet session and watching you change your password. The second problem is trust: use of any of the r-commands requires root .rhosts files on various machines, and use of NFS requires export of sensitive files. Both problems, however, are eminently solvable. If you already have worked out what the .rhosts or exports implications are for your organization, you merely need to check to ensure that allowing rsh/nfs to support password update doesn't break your trust rules. If you are small, at home, or behind a firewall, you probably don't have a lot to worry about. And if you do need secure, untappable, and trusted channels to selected machines, you can use several programs to make encrypted connections to other machines: either ssh, the Secure SHell, or the new skip program of the IETF.
About the Author
Dave is a consulting systems administrator (something like a consulting detective) in the Toronto area. His primary interests are with email and public policy issues, and he admits to having been the postmaster for a large university and a systems and network manager for several successful R&Dfirms. He can be reached at davecb@hobbes.ss.org.
|