Remote Password Update
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
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
from it would be more efficient. This article introduces
password update program that Iuse to steamline these
There are lots of ways to update password files for
including sneakernet. Most are rather complicated. One
requires you to dedicate a machine just to the management
and "tickets." Another (YP) assumes that every
machine you have will
store all the main configuration tables under the control
of a single
This is not the simple, single, elegant solution I normally
see on UNIX. So, several years ago, I set out to provide
mechanism that used only rather pedestrian UNIX networking
(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
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
There are only two parts to the program: the first arranges
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
appears deceptively simple: all they need to do is run
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.
has as its shell a program that prompts you for your
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
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
(see the security section below).
passwdd::0:10:The Password-Changing Account:/:/etc/passwdd
This program (/etc/passwdd) gets the username from the
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
In pseudocode, this is:
if (encrypt(getpass()) == getpwent(user)->pw_passwd)
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
looks harder, but is actually much easier: cron can
use any of at least
five perfectly good ways.
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:
rdist is convenient, because it runs a script after
therefore doesn't require a crontab entry on the client.
particularly good for a centralized implementation,
in which all the
clients trust rsh commands from a central password server.
track is also good. It strictly "pulls"
from a server to a client that
subscribes to the password service. It reverses the
relationship: the server trusts the clients, which is
If rdist or track won't work on all your machines,
then you can use
rcp to copy files and rsh to run the installation command,
but either or
both can fail silently.
You can also simulate rcp with rsh server cat /etc/passwd
>safe-place, which works reliably even on the worst
systems, such as an
"ursus horribilis" that I used to administer.
NFS is another good means, with quite a different
set of access
controls than the r-commands: The server exports a filesystem
the data to a limited list of clients.
ftp also works, at the cost of finding a noninteractive
and at the risk of sending an ftp password clear across
Well, perhaps, if you don't actually mind crackers.
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
suitable safety checks. The script could be as simple
if [ ! -f /etc/ptmp ]; then
cp /some/safe/place/in/root /etc/ptmp
mv /etc/ptmp /etc/passwd
That's almost what I've done, but without the race condition.
is in "The Client Password Update Script"
(see Listing 3).
Note that it is somewhat harder if the machines are
because that requires you to decompose the password
file into the root
password, system-specific passwords, and common passwords,
reassemble a password file with system-specific entries
on the client.
In this case, the password for root might be any of
common to all the machines in a group,
peculiar to each one, or
common to a subset of the group.
In other words, you can adapt the program to multiple
machines, each with its own systems administrators.
All of those
decisions can be made in the script that puts the password
on the client machine, and it only adds a few lines
to the example
At this point, you're done; password changes start with
that they're occuring on a different machine and end
with a message
about when they will be universally available. Everything
quietly in the background.
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
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
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
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
privileged program. This sounds horrible, but in fact,
the security of
the combination of programs is exactly as good as the
/bin/passwd. The added programs merely authenticate
a person and then
run /bin/passwd. It is easy enough to read the program
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
There is one extra risk to setuid-root programs. Because
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
systems administrator, so we merely need to make the
same as root's. For that reason, passwdd is the account's
shell, with a
very minimal environment.
You should be aware of two broad problems in network
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
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
Both problems, however, are eminently solvable. If you
worked out what the .rhosts or exports implications
are for your
organization, you merely need to check to ensure that
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
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
successful R&Dfirms. He can be reached at email@example.com.