I'm reading "Reliably Deploying Rails Applications"

Regarding defining users to be set up by Chef, it says:

“Next we need to define users, inside data_bags/users copy the file deploy.json.example to deploy.json.

Generate a password for your deploy user with the command:

openssl passwd -1 "plaintextpassword"

And update deploy.json accordingly.”

My question is, what is the purpose of openssl passwd? Is it just to generate a strong password? Would it be just as good if I typed in random characters?

And then, what is my 'actual' password? The plain text version, or the encrypted version? Do I need to save a copy of both to my password manager?


Yes, I have read the manual. And yes, I understand that it generates an md5 encrypted version of my password. My question is more about why you'd use it, as opposed to using a very secure random string of characters that you make up yourself (or generate with a password generator).

One benefit I could think of is that you could type a rememberable password, and run it through openssl passwd -1 "plaintextpassword" every time you need to enter it. So you'd kind of have the best of both worlds in terms of an easy to remember password, and a secure, random password. And running the rememberable/plain text version through ``openssl passwd -1` every time you need it would save you having to store the encrypted version of the password and type / paste that in every time you need to enter your password.

Is that the only benefit? If not, what are the others?


2 Answers 2


The purpose of that command is to feed your password through a one-way hashing algorithm (-1 outputs MD5). What that gets you is a string that's derived from your password cryptographically, but cannot be used to find your password on its own if an attacker gets their hands on the hashed version (theoretically - there's a salt included which helps against rainbow tables, but an attacker can still brute force effectively against it).

Your password being run thorough the hashing function will always result in the same hash, which can then be compared by the server to the stored hash to verify that you have the same password as was run through the openssl command.

  • Thanks. My question is more: Given that all I store in deploy.json is the encrypted version, do I have any use for the non-encrypted version? When I type my password, don't I have to use the encrypted version anyway? Is the purpose of using this method simply so that I could have a rememberable password, and then run it through openssl passwd every time I wanted to use it, as opposed to typing the encrypted version out? Feb 11, 2014 at 2:22
  • I've updated my question with a little more explanation of what I'm after. Feb 11, 2014 at 2:31
  • 1
    @joshua.paling The benefit of the MD5 password is that you can authenticate to the server using the original password, without the server storing the original password in plain text. You'll be using your original password to authenticate to the application, which will then hash it with MD5 and compare to the stored MD5. Feb 11, 2014 at 3:10

After some chat on the #chef IRC channel, here's what I ultimately needed to know. Most of it is actually peripheral info, rather than openssl passwd specific, but anyway...

Chef users the standard adduser command (http://linux.die.net/man/8/adduser) for adding users. That command accepts the password already encrypted - Hence why you need to store an encrypted version (generated by openssl passwd -1 "plaintextpassword") in your data_bags/users/deploy.json.

So, your plain-text password is the 'real' password. But because the adduser command expects the password you pass it to be already encrypted, it's the encrypted version that you need to store in data_bags/users/deploy.json

That works well, because you definitely wouldn't want to store a plain-text password in data_bags/users/deploy.json!

Coming back to my original questions:

What is my 'actual' password? The plain text version, or the encrypted version?
The plain text version is your real one.

Do I need to save a copy of both to my password manager? No. You only store your plain-text version. You use that whenever you want to log in. The system then encrypts that, and compares it to the encrypted version that it has stored for your account.

What is the benefit / purpose of openssl passwd?

There is no 'benefit' as such. It's simply required because the adduser command will expect the password it's given to be already encrypted.

Having said all that, apparently it's much better to not sore a password at all in data_bags/users/deploy.json, and only allow access via SSH Keys.

It's not considered a good practice to store even an encrypted version of your password in data_bags/users/deploy.json because Linux password encryption has such a bad track record. (edit: read comments below for a better explanation)

  • 3
    because Linux password encryption has such a bad track record That's not really an accurate representation - it's more a problem of giving an attacker access to your hashed password, which they can then take and brute force (to attempt to recover your original password) on their own system - and since MD5 is a comparatively fast to compute algorithm, an attacker might be able to make hundreds of thousands or millions of guesses at your password per second. MD5 is an industry standard, and it's not recommended for use these days due to weaknesses which are not specific to Linux. Feb 11, 2014 at 3:55
  • 1
    Not having a password attached to the user at all could have some security advantages, but also has potential drawbacks - you will likely want to be able to SSH with a key then sudo with a password. Since you're just setting the user account's hashed password in the shadow file, consider storing it using a stronger algorithm - see here. Feb 11, 2014 at 4:00
  • Thank you. Helpful inquiry and explanations. I would like to add also that openssl passwd -1 "plaintextpassword" produces an output whose second field being the randomly chosen salt in the hashing process. You can also personally choose the salt via the -salt argument of openssl. This 2nd field is very, very important because it is the only link to the original data being hashed. Hence, it is used to prove equivalence.
    – daparic
    Sep 30, 2019 at 10:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .