Я читаю "Надежное развертывание приложений Rails"
Что касается определения пользователей, которые будут созданы Chef, он говорит:
«Затем нам нужно определить пользователей, внутри data_bags / users скопируйте файл deploy.json.example в deploy.json.
Сгенерируйте пароль для своего пользователя развертывания с помощью команды:
openssl passwd -1 "plaintextpassword"
И соответственно обновите deploy.json ».
У меня вопрос, какова цель openssl passwd? Это просто для создания надежного пароля? Было бы так же хорошо, если бы я набирал случайные символы?
И затем, каков мой «настоящий» пароль? Версия в виде обычного текста или зашифрованная версия? Нужно ли мне сохранять копию обоих в моем диспетчере паролей?
ОБНОВИТЬ:
Да, я прочитал инструкцию. И да, я понимаю, что он генерирует зашифрованную версию моего пароля md5. Мой вопрос больше о том, зачем вы его используете, а не об использовании очень безопасной случайной строки символов, которую вы составляете самостоятельно (или генерируете с помощью генератора паролей).
Одно из преимуществ, о котором я мог подумать, это то, что вы можете ввести запоминающийся пароль и запустить его через openssl passwd -1 "plaintextpassword" каждый раз, когда вам нужно ввести его. Таким образом, у вас будет лучшее из обоих миров с точки зрения легко запоминающегося пароля и безопасного случайного пароля. И запуск запоминаемой / простой текстовой версии через openssl passwd -1 каждый раз, когда вам это нужно, избавит вас от необходимости хранить зашифрованную версию пароля и вводить / вставлять ее каждый раз, когда вам нужно вводить пароль.
Это единственное преимущество? Если нет, то каковы другие?
Цель этой команды - передать ваш пароль через односторонний алгоритм хеширования (-1 выходы MD5). В результате вы получаете строку, которая получена из вашего пароля криптографически, но не может использоваться для поиска вашего пароля самостоятельно, если злоумышленник получит в свои руки хешированную версию (теоретически - есть соль, которая помогает против радужные столы, но злоумышленник может грубая сила эффективно против него).
Ваш пароль, который запускается с помощью функции хеширования, всегда будет приводить к одному и тому же хешу, который затем может быть сравнен сервером с сохраненным хешем, чтобы убедиться, что у вас тот же пароль, который был запущен через openssl команда.
После некоторого разговора на IRC-канале #chef, вот что мне в конечном итоге нужно было знать. По большей части это периферийная информация, а не openssl passwd конкретный, но все равно ...
Повар использует стандарт adduser команда (http://linux.die.net/man/8/adduser) для добавления пользователей. Эта команда принимает пароль уже зашифрован - Следовательно, почему вам нужно хранить зашифрованную версию (сгенерированную openssl passwd -1 "plaintextpassword") в твоем data_bags/users/deploy.json.
Итак, ваш простой текстовый пароль является «настоящим» паролем. Но поскольку adduser команда ожидает, что пароль, который вы ей передаете, будет уже зашифрованным, это зашифрованная версия, которую вам нужно сохранить в data_bags/users/deploy.json
Это хорошо работает, потому что вы определенно не захотите хранить пароль в виде простого текста в data_bags/users/deploy.json!
Возвращаясь к моим первоначальным вопросам:
Какой у меня «настоящий» пароль? Версия в виде обычного текста или зашифрованная версия?
Текстовая версия - это ваша настоящая версия.
Нужно ли мне сохранять копию обоих в моем диспетчере паролей? Нет. Вы храните только текстовую версию. Вы используете это всякий раз, когда хотите войти в систему. Затем система зашифровывает это и сравнивает с зашифрованной версией, сохраненной для вашей учетной записи.
В чем преимущество / цель openssl passwd?
Нет никакой выгоды как таковой. Это просто необходимо, потому что adduser команда будет ожидать, что введенный пароль уже зашифрован.
Сказав все это, очевидно, что гораздо лучше вообще не ломать пароль в data_bags/users/deploy.json, и разрешить доступ только через ключи SSH.
Не рекомендуется хранить даже зашифрованную версию вашего пароля в data_bags/users/deploy.json потому что шифрование паролей Linux имеет плохую репутацию. (изменить: прочтите комментарии ниже для лучшего объяснения)