> It is no surprise to get an x in this field when the program
This is the point I have been trying to get across. You *cannot* depend
on getpwnam() + crypt for password information. getpwnam() returns
entries from /etc/passwd, which on most modern systems doesn't actually
contain crypted passwords.
If you want to support shadow passwords, take a look at the "Linux
shadow password HOWTO", part of the Linux Documentation Project:
Using something like PAM means you get a single, consistent interface to
work with regardless of what the system is using for authentication.
It's *not* available everywhere, but it's available on Linux, OS X,
Solaris, FreeBSD, NetBSD, and elsewhere.
Take a look at 'auth.c' from the OpenSSH source -- this has support for
plain getpwnam(), getpwnam() + shadow passwords, and pam.
Well, maybe. This is true if you're using the MD5 version of crypt,
which is triggered if you pass it a salt starting with '$1$', in which
case the salt can be up to eight characters.
Non-md5 passwords only have a two-character salt.
As you mentioned, using the original password as a salt will always do
the right thing.
Lars Kellogg-Stedman < XXXX@XXXXX.COM >
This email address will expire on 2005-11-23.