У меня есть устройство, которое обновляется с CentOS 5 до CentOS 6. На исходном сервере все пользователи имеют пароли MD5. На обновленном сервере теперь используются пароли SHA-512.
Пользователи, которые изменили свой пароль и имеют пароль SHA-512 в /etc/shadow
так как обновление может использовать crontab
успешно, но пользователи, которые не изменили свой пароль и все еще имеют старый пароль MD5, не могут использовать crontab
. Они получают следующее сообщение об ошибке:
Authentication service cannot retrieve authentication info
You (_username_) are not allowed to access to (crontab) because of pam configuration.
Я смотрел на /etc/pam.d/system-auth
(ты тоже можешь), но я не совсем уверен, что нужно настроить, чтобы разрешить доступ к crontab для пользователей, которые еще не изменили свои пароли.
Я прекрасно понимаю, что могу заставить всех сменить пароли с помощью chage -d 0
, и пользователи, изменившие свой пароль, восстановят доступ к crontab (и к тому, что еще может быть сломано), но у меня есть несколько пользователей, которым мне нужно отредактировать их crontab перед их следующим входом в систему, и используя crontab -e -u _username_
как root также не работает с той же ошибкой, что и выше.
Как ни странно, эта проблема не появилась в моем окне разработчика; Я столкнулся с этим в промежуточной коробке незадолго до развертывания. Пользователи в окне разработчика со старыми паролями MD5 могут получить доступ к crontab нормально, а /etc/pam.d/system-auth
идентично. Ящики для разработчиков и промежуточные блоки должны быть идентичными, за исключением их IP-адресов. Я подозреваю, что пропустил что-то действительно очевидное и глупое ...
Итак, мой вопрос: как я могу разрешить доступ к crontab для пользователей, которые еще не изменили свои пароли и были хешированы SHA-512? Или как я могу обойти эту проблему?
Мне удалось исправить эти моменты после публикации вопроса.
Получается, что /etc/shadow
записи для затронутых пользователей пароля MD5 каким-то образом имели поле после дублирования хешированного пароля, из-за чего PAM не мог интерпретировать строку. Другими словами, плохая работа по вырезанию и вставке.
Мне не хватило кофе ...
У меня тоже была эта проблема, и оказалось, что в / etc / shadow нет записи для этого пользователя. С помощью pwck добавил пользователя, и проблема была решена.
Были такие же проблемы. Если вам не нужен точный пароль для учетной записи, просто запустите:
pwconv