1

I have a mail benchmarking application that I need to set up, and part of that includes setting up at least several hundred dummy user accounts.

I had this scripted so I could easily recreate the mailstore, like such:

#!/bin/bash

NEW_USERS="./userlist"
HOME_BASE="/home/"

cat ${NEW_USERS} | \
while read USER PASSWORD
do
useradd -p ${PASSWORD} -m -d ${HOME_BASE}${USER} ${USER}
done

exit 0

This seemed to work, but then my application freaked out. When I went to check, none of my accounts had working logins! They all had empty passwords.

(Note: The above script worked for a previous install of 12.04 LTS Server, see below)

I tried just the following:

useradd -p pass -m test

But that failed similarly. Running the password through crypt makes no difference whatsoever.

The interesting thing is that the script was working on another install of Ubuntu 12.04 Server! It was a slightly different image (ubuntu-12.04-server-cloudimg-amd64-disk1 as opposed to my current ubuntu-12.04.3-server-amd64), but why would something so basic change in function (or, it seems, stop working altogether!)?

Any help would be greatly appreciated as I do not look forward to manually adding hundreds of users.


EDIT: Here is some output from /var/log/auth.log:

Oct 16 01:47:33 mailserver-vm su[27735]: Successful su for ubuntu by root
Oct 16 01:47:33 mailserver-vm su[27735]: + /dev/pts/0 root:ubuntu
Oct 16 01:47:33 mailserver-vm su[27735]: pam_unix(su:session): session opened for user ubuntu by root(uid=0)
Oct 16 01:47:36 mailserver-vm su[27790]: pam_unix(su:auth): authentication failure; logname=root uid=1000 euid=0 tty=/dev/ pts/0 ruser=ubuntu rhost=  user=test1
Oct 16 01:47:38 mailserver-vm su[27790]: pam_authenticate: Authentication failure
Oct 16 01:47:38 mailserver-vm su[27790]: FAILED su for test1 by ubuntu
Oct 16 01:47:38 mailserver-vm su[27790]: - /dev/pts/0 ubuntu:test1
Oct 16 01:47:45 mailserver-vm su[27791]: pam_unix(su:auth): authentication failure; logname=root uid=1000 euid=0 tty=/dev/ pts/0 ruser=ubuntu rhost=  user=test2
Oct 16 01:47:47 mailserver-vm su[27791]: pam_authenticate: Authentication failure
Oct 16 01:47:47 mailserver-vm su[27791]: FAILED su for test2 by ubuntu
Oct 16 01:47:47 mailserver-vm su[27791]: - /dev/pts/0 ubuntu:test2
Oct 16 01:47:56 mailserver-vm su[27792]: pam_unix(su:auth): authentication failure; logname=root uid=1000 euid=0 tty=/dev/ pts/0 ruser=ubuntu rhost=  user=test50
Oct 16 01:47:59 mailserver-vm su[27792]: pam_authenticate: Authentication failure
Oct 16 01:47:59 mailserver-vm su[27792]: FAILED su for test50 by ubuntu
Oct 16 01:47:59 mailserver-vm su[27792]: - /dev/pts/0 ubuntu:test50

As you can see, I attempt an su from root to my normal user account first (since I need to check if their passwords are working). Attempting to su into any of the accounts ends in failure, although their password should be set equal to their username (ie. test1:test1, test2:test2, ...)

In addition, the accounts are assigned bash:

root@mailserver-vm:~/scripts# su test1
test1@mailserver-vm:/root/scripts$ cd
test1@mailserver-vm:~$ ps -p $$
  PID TTY          TIME CMD
31484 pts/0    00:00:00 bash
test1@mailserver-vm:~$

Attempting to run the commands myself yields no output whatsoever - the command seemingly completes successfully.

For example: here is the output of useradd -p t123 post:

root@mailserver-vm:~/scripts# useradd -p t123 post
root@mailserver-vm:~/scripts# 
root@mailserver-vm:~/scripts# su ubuntu
ubuntu@mailserver-vm:/root/scripts$ su post
Password:                <--- t123 entered
su: Authentication failure

Output of grep post /etc/passwd /etc/shadow:

/etc/passwd:post:x:1013:1013::/home/post:/bin/sh
/etc/shadow:post:t123:15994:0:99999:7:::

For the record, running the password through crypt had the same result. This is the way I did it:

# password = whatever
# pass=$(perl -e 'print crypt($ARGV[0], "password")' $password)
$ useradd -p $pass user

EDIT: I ended up using chpasswd to change the passwords afterwards, but I'm still baffled as to why useradd -p stopped working from a previous 12.04 install. I couldn't really find anything relevant (perhaps an update discarded cleartext input for the password field, as gertvdijk said below. Although I've fixed my issue, if anyone wishes to provide an answer to the original question I would gladly accept it.

  • 2
    How exactly are you trying to log in? What do the logs say about that login attempt? (/var/log/auth.log) Do your users have a shell assigned? What happens if you run the command on the command line yourself (so you can see error output if any)? What does the passwd/shadow file contain? Run sudo grep username /etc/passwd /etc/shadow for an entry. Please include such details in your question. – gertvdijk Oct 16 '13 at 6:46
  • Thank you for the recommendations. I've updated the post with answers to all the questions you asked, but unfortunately found no useful information. – user991710 Oct 16 '13 at 7:04
  • 1
    I see what you did there. The password you provide is in plaintext which will not be evaluated most likely. It's in clear text in the shadow file! <-- you security hairs should raise straight up! Please include the attempt where you run the password through crypt. However, I think it's better if you would use mkpasswd -m sha-512 or set the password after you created the account using passwd. – gertvdijk Oct 16 '13 at 7:11
  • Hm, that is odd. It was my intention to merely provide a plaintext pass so I can set it up rather fast. It worked on the previous install, too! Is there a way to force evaluation, then? The server is on a private network and will only serve for local use, so I did not really need any additional security. – user991710 Oct 16 '13 at 7:15
  • I wonder if pam is blocking the passwords your defining? I've found pam to be an f'ing nightmare when all you want is quick setup on an isolated test box. – djeikyb Oct 16 '13 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.