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?

200_success
  • 4,701
  • 1
  • 24
  • 42
BadToTheBone
  • 369
  • 1
  • 3
  • 9
  • I don't see a question there? - Such things are managed through PAM and typically logged in `/var/log/secure` – HBruijn Dec 17 '14 at 14:40
  • @HBruijn I have updated my answer to show what is written to */var/log/secure* – BadToTheBone Dec 17 '14 at 14:45
  • 2
    Really? +12 for a question that is explicitly answered by the relevant man page? – user Dec 18 '14 at 11:54
  • Note that [in a password hash, `$1$` indicates MD5 is used](http://superuser.com/a/622895/53590). 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 '14 at 11:56
  • 2
    Side note: passwords in `/etc/shadow` are not encrypted but hashed – Tobias Kienzler Dec 18 '14 at 12:04
  • You can use `adduser` instead, if your distro has it. – Halfgaar Dec 18 '14 at 13:10

3 Answers3

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.

Cristian Ciupitu
  • 6,226
  • 2
  • 41
  • 55
kasperd
  • 29,894
  • 16
  • 72
  • 122
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.

D.W.
  • 206
  • 4
  • 13
faker
  • 17,326
  • 2
  • 60
  • 69
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.

Cristian Ciupitu
  • 6,226
  • 2
  • 41
  • 55
Dennis Williamson
  • 60,515
  • 14
  • 113
  • 148
  • 2
    Don't use MD5! Use SHA-2 – Josef Dec 17 '14 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 '14 at 11:53
  • @MichaelKjörling: A **very** good point. Please see my edited answer. – Dennis Williamson Dec 18 '14 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 '14 at 13:01
  • @MichaelKjörling: The file can have 600 permission which will make it readable only to the owner of the file. And when you're finished, `rm` the file. This is much more secure than have the password show up in the output of `ps`. – Dennis Williamson Dec 18 '14 at 15:37
  • 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 '14 at 15:48