21

I stumbled accross this problem when trying to create new FTP users for vsftpd. Upon creating a new user with the following command and attempting login with FileZilla, I would get an "incorrect password" error.

useradd f -p pass -d /home/f -s /bin/false

After doing this, /etc/shadow contains

f:pass:1111:0:99:2:::

Once I run the following command and provide the same pass pass

passwd f

/etc/shadow contains

f:$1$U1c5vVwg$x5TVDDDmhi0a7RWFer6Jn1:1111:0:99:2:::

It appears that encryption happens when I run passwd, but doesn't upon useradd

Importantly after doing this, I am able to login to FTP with the exact same credentials.

I am using CentOS 5.11, vsftpd for FTP, and FileZilla for FTP Access

/var/log/secure contains:

Dec 17 useradd[644]: new group: name=f, GID=511
Dec 17 useradd[644]: new user: name=f, UID=511, GID=511, home=/home/f, shell=/bin/false

Why does it not work when I pass -p pass to useradd? What do I need to do to make it work?

6
  • I don't see a question there? - Such things are managed through PAM and typically logged in /var/log/secure
    – HBruijn
    Dec 17, 2014 at 14:40
  • @HBruijn I have updated my answer to show what is written to /var/log/secure Dec 17, 2014 at 14:45
  • 2
    Really? +12 for a question that is explicitly answered by the relevant man page?
    – user
    Dec 18, 2014 at 11:54
  • Note that in a password hash, $1$ indicates MD5 is used. MD5, while not outright terrible for passwords, is rather on the weak side these days. It's an entirely separate question, but I would absolutely urge you to consider migrating to a stronger hash function.
    – user
    Dec 18, 2014 at 11:56
  • 2
    Side note: passwords in /etc/shadow are not encrypted but hashed Dec 18, 2014 at 12:04

3 Answers 3

44

That is working as intended. If you want to set a password using the useradd command, you are supposed to give a hashed version of the password to useradd.

The string pass does satisfy the format criteria for the hashed password field in /etc/shadow, but no actual password hashes to that string. The result is that for all intents and purposes, that account will behave as having a password, but any password you try to use to access it will be rejected as not being the correct password.

See man useradd or the useradd documentation:

-p, --password PASSWORD

The encrypted password, as returned by crypt(3). The default is to disable the password.

Note: This option is not recommended because the password (or encrypted password) will be visible by users listing the processes.

You should make sure the password respects the system's password policy.

32

manuseradd:

   -p, --password PASSWORD
       The encrypted password, as returned by crypt(3). The default is to
       disable the password.

You are supposed to pass a hashed password to it.
Not a plaintext password.

16

useradd expects you to pass it the hash of the password, not the password itself. You can use the following variation on your command to provide a hashed password to the useradd command:

useradd f -p "$(mkpasswd --method=sha-512 'pass')" -d /home/f -s /bin/false

To find out the methods available, use:

mkpasswd --method=help

In order to avoid passing the password on the command line, put the password in a file (using an editor and not using echo or similar) and do this:

useradd f -p "$(mkpasswd --method=sha-512 --password-fd=0 < filename)" -d /home/f -s /bin/false

This will pass the hashed password on the command line, but not the plaintext one.

mkpasswd comes with the expect package.

6
  • 2
    Don't use MD5! Use SHA-2
    – Josef
    Dec 17, 2014 at 23:55
  • 9
    Do note that this temporarily exposes the password through the various kernel interfaces (any process is allowed to read the command line of any other process) and may result in it being saved in plain text to disk through $HISTORY or similar mechanisms.
    – user
    Dec 18, 2014 at 11:53
  • @MichaelKjörling: A very good point. Please see my edited answer. Dec 18, 2014 at 12:55
  • 1
    Of course, you're still storing the plain text password on disk. At least, this gives the sysadmin a choice. Maybe at this point we're better off just using a dummy password at first and immediately running passwd to change it to something else......
    – user
    Dec 18, 2014 at 13:01
  • 2
    Absolutely Dennis, it's much better, but the password still ends up on the disk in plain text. In some situations and under certain threat models, that can be a real problem. It doesn't have to be.
    – user
    Dec 18, 2014 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .