Пользователи не могут использовать crontab после обновления пароля
У меня есть окно, которое обновляется с 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 также завершается с той же ошибкой, что и выше.
Как ни странно, эта проблема не появилась на моей коробке разработчика; Я столкнулся с этим на этапе подготовки непосредственно перед развертыванием. Пользователи на коробке dev со старыми паролями MD5 могут получить доступ к crontab просто отлично, и /etc/pam.d/system-auth
идентичен Предполагается, что блоки dev и staging идентичны, за исключением их IP-адресов. Я подозреваю, что пропустил что-то действительно очевидное и глупое...
Итак, мой вопрос: как я могу разрешить доступ к crontab для пользователей, которые еще не изменили свои пароли и были хешированы SHA-512? Или как я могу обойти эту проблему?
3 ответа
Мне удалось исправить эти моменты после публикации вопроса.
Оказывается, что /etc/shadow
записи для затронутых пользователей пароля MD5 каким-то образом имели поле после дублирования хешированного пароля, в результате чего PAM не мог интерпретировать строку. Другими словами, плохая работа.
Мне не хватило кофе...
У меня тоже была эта проблема, и оказалось, что в /etc/shadow нет записи для этого пользователя. Использование pwck добавило пользователя и проблема была решена.
Были те же проблемы. Если вам не нужен какой-то точный пароль для учетной записи, просто запустите:
pwconv