Generating Passwords Using crypt(3)

When writing things like Red Hat Kickstart scripts, or using useradd, or in many other cases, a password is required in the format generated by crypt(3). However, how do we generate a password in this format? In fact, there are many, many ways – if you just know what they are.

One way is to use mkpasswd. This utility is made just for this very purpose; to generate a password with crypt(3) use the command:


The program will ask for a password, and generates a crypt(3) output string.

If you have the Apache web server loaded, you can use htpasswd. Use this command

htpasswd -nd user

The name of the user doesn’t matter, as it is the password we want. The output will be in the format user:password; just copy the password and you’re set.

If you have OpenSSL available, you can use the openssl command:

openssl passwd -crypt myPassword

Replace myPassword with the password you want to encrypt.

The other methods all require putting the password into the command line in plain text. This can be a problem: the process list (seen using ps) will have the password in it as long as the program runs. The password will also go into the shell history.

One way around this – with programming languages – is to use a script or to use the language’s interpreter.

Using Perl:

perl -e "print crypt('password','sa');"

Perl requires a salt ('sa' in the example).

Ruby can generate a crypt-formatted password, but it requires a salt:

ruby -e 'print "password".crypt("JU"); print("\n");'

Using PHP, you can generate a password from the UNIX command line this way:

php -r "print(crypt('password','JU') . \"\n\");"

Note that if you do not provide a salt ('JU' in the example) then the string returned may not be in crypt format, but rather in MD5 format. Thus, while the salt is an optional parameter, it is necessary in this case.

Using Python requires importing the crypt library – and it requires a salt:

python -c 'import crypt; print crypt.crypt("password","Fx")'

Again, the salt in this case is the second parameter or "Fx".

Databases can generate crypt passwords too; using MySQL it can be done like this:

echo "select encrypt('password');" | mysql

For Tcl there are a number of options; if you are using Ubuntu, you could give the trf package a try. If using Lua, there is the lua-crypt extension.

Feel free to add other options below – with working command-line examples.

Locking out root!

This is not as far fetched as it sounds; every Macintosh OS X system comes configured in this way: it is impossible to log in as root.

How does one do things as root then? I shall reveal the secret…

First of all, one needs to make sure that the program sudo is available and correctly configured. It must be configured to allow you (or the system owner) to switch to root. Best to test this directly before doing anything to the root account.

Once you have verified that you can switch to root using sudo, then it is time to actually lock the root account. Before doing so, open a root shell using sudo or a direct log in as root. Then execute:

# passwd -l root

There! Now no one can log in as root – don’t you feel much better? Well…. you can become root (by using sudo) but logging in directly as root is impossible.

If passwd does not recognize the -l option, then just put an asterisk (*) into the password field, wherever it is. HP-UX, Linux, and Solaris all recognize the -l option; FreeBSD uses the -l option for a different purpose.

For FreeBSD (and quite probably, OpenBSD and NetBSD as well), use the vipw command to lock out not only the root account, but the toor account as well. The toor account is identical to the root account (including userid) but allows user customization.

When combined with the wheel group, this will lock down your root account quite effectively. Just don’t stop there: remember to use multiple defenses. However, that’s a topic for another day.

Update: This is most useful in situations where a normal user will always have access (workstations come to mind).  If your normal users are authenticated via NIS, or Active Directory, or LDAP, don’t do this! If root logins are locked out, and none of the users can log in…….. then what?  Uh oh….