Useradd using crypt password generation

Question

I am working on what I thought was a very simple script to dynamically create an FTP user using 'useradd' There are several parts of this process I am unfamiliar with, and an entire day's research has not gotten me too far. Here is what I have:

password="pass"
pass=$(perl -e 'print crypt($ARGV[0], "wtf")' $password)
useradd -d HOME_DIR -s /bin/bash -g GROUP -p $pass -f -1 testing

Notes

1. HOME_DIR and GROUP are placeholders
2. I am not having issues with the home/base_dir (-d, -b) or group (-g) functionality of 'useradd'

Topics:

1. Why are my password generation efforts not working?
2. is /bin/bash the correct shell to use for a purely FTP user, or would I use /bin/false or a different shell?
3. By default, useradd disables an account until they provide their own password, how do I bypass this?
4. I do not want to use the passwd utility as it cripples my ability to automagically generate FTP accounts, I found a solution to this here, but I do not understand the solution

Let me know if I am going about this all wrong, or if what I am trying to do is not possible or if I am misinformed about anything I have stated herein. Thank you for any help you can provide. :D

Answer 1

If you want to create "FTP only" users, you should look at rssh Install rssh for your distro, and set the shell for the "FTP only" user to "/usr/bin/rssh"

Works very well

Answer 2

Regarding password generation:

32.3 Encrypting Passwords

• Function: char * crypt (const char *key, const char *salt)

  The crypt function takes a password, key, as a string, and a salt character array which is described below, and returns a printable ASCII string which starts with another salt. It is believed that, given the output of the function, the best way to find a key that will produce that output is to guess values of key until the original value of key is found.

  The salt parameter does two things. Firstly, it selects which algorithm is used, the MD5-based one or the DES-based one. Secondly, it makes life harder for someone trying to guess passwords against a file containing many passwords; without a salt, an intruder can make a guess, run crypt on it once, and compare the result with all the passwords. With a salt, the intruder must run crypt once for each different salt.

  For the MD5-based algorithm, the salt should consist of the string $1$, followed by up to 8 characters, terminated by either another $ or the end of the string. The result of crypt will be the salt, followed by a $ if the salt didn't end with one, followed by 22 characters from the alphabet ./0-9A-Za-z, up to 34 characters total. Every character in the key is significant.

  For the DES-based algorithm, the salt should consist of two characters from the alphabet ./0-9A-Za-z, and the result of crypt will be those two characters followed by 11 more from the same alphabet, 13 in total. Only the first 8 characters in the key are significant.

  The MD5-based algorithm has no limit on the useful length of the password used, and is slightly more secure. It is therefore preferred over the DES-based algorithm.

  When the user enters their password for the first time, the salt should be set to a new string which is reasonably random. To verify a password against the result of a previous call to crypt, pass the result of the previous call as the salt.

Depending on your system, there may also be Blowfish or SHA-2 family crypts as well, and it's possible that the traditional DES may be disabled for security. PAM can add its own complications in here too.

     ID       |    Method
  -------------------------------
     1        |  MD5 (Linux, BSD)
     2a       |  Blowfish (OpenBSD)
     md5      |  Sun MD5
     5        |  SHA-256 (Linux, since glibc 2.7)
     6        |  SHA-512 (Linux, since glibc 2.7)

That being said, the

root# useradd -d / -g users -p $(perl -e'print crypt("foo", "aa")') -M -N foo
user$ su - foo
Password: foo
foo$ ^D
root# userdel foo

works just fine on my system.

---

Regarding the shell:

/sbin/nologin is traditional for login-disabled users. You'll have to double-check your FTP daemon's configuration to see if that excludes them from FTP access.

---

Regarding the disabled account:

As seen above, works for me, as expected if given a working password.

---

About the other solution:

What don't you understand about the alternate solution? It seems very clear to me.

Just pipe "username:password" into "chpasswd".

---

If you want FTP-only users, I would recommend using a FTP daemon that supports virtual users like glftpd, Pure-FTPd, ProFTPD, vsftpd, ... actually it seems that all the common ones do. This way, an FTP account does not require a real system account.