Unattended Password Creation Failing?

Earlier, I was asked if I had any good solutions for scripting a user account generator in bash -- asking the user what they had already, I received:

useradd -n -g users -p [password] -s /bin/false [username]

I asked what the problem seemed to be, and the response was the password didn't seem to work -- if they used 'passwd' interactively, it'd work -- but unattended, it failed.

Having a look at the useradd manual, we see:

-p -- The encrypted password, as returned by crypt(3).

After trying various combinations - I thought about OpenSSL. What if I gave it the password and got it to do the crypt work first, then fed the encrypted string to useradd?

Something like:

#!/bin/bash
clear="[password]"
crypt="openssl passwd -crypt $clear"

success="0"
failure="1"

useradd -n -g users -p $crypt -s /bin/false [username]

exit $?

Cut and Paste the above into a script and instantly you have a semi-autonomous way of adding generated (or defined) passwords to your machine, all with the help of OpenSSL.

OpenSSL Vulnerability for Ubuntu 6.06 LTS

Had a phone-call earlier about this as well as a few e-mails since DSA 1571-1 appeared, so i thought i'd post this here in order to respond to multiple birds with one stone.

Servers that run Ubuntu 6.06 LTS in it's default configuration (or it's LAMP configuration) are not vulnerable to the OpenSSL problem, because they are running OpenSSL 0.9.7, not 0.9.8c-1, which is the first version to exhibit the bug.

Systems which are running any of the following releases are vulnerable to this bug:

• Ubuntu 7.04 (Feisty)


• Ubuntu 7.10 (Gutsy)


• Ubuntu 8.04 LTS (Hardy)


• Ubuntu “Intrepid Ibex” (development): libssl <= 0.9.8g-8


• Debian 4.0 (etch) (see corresponding Debian security advisory)

This is not mean that you shouldn't check your users keys -- if you've got users who use affected versions of Debian or Ubuntu (above), you should use the dowkd.pl script available here (GPG key) with the user option to scan your servers for users who have potentially compromised keys.

You can scan the local server using:

perl dowkd.pl host localhost

... and local users with keys using:

perl dowkd.pl user

If you see something like:

/home/[username]/.ssh/id_dsa.pub:1: weak key

You should re-generate keys for that user, using:

ssh-keygen -t [rsa/dsa] -b [1024/2048/4096]

... depending on your individual security needs.

note: If you see:

/home/[username]/.ssh/id_dsa.pub:1: 2048 bits DSA key not recommended

You are not necessarily vulnerable, there's nothing wrong with using 2048-bit DSA keys, as longer key lengths provide better security at the cost of decreased performance.

note II: Using a blank passphrase for your public key is strongly discouraged -- if a would-be-intruder can just press the ENTER key to enter your machine, what security is a public key?

(The most-used analogy I have for passphrase-less SSH keys is: 'A public key with a passphrase is like a door with a lock -- without one, it's just a door.)