Назад | Перейти на главную страницу

Пользователи не могут использовать 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 также не работает с той же ошибкой, что и выше.

Как ни странно, эта проблема не появилась в моем окне разработчика; Я столкнулся с этим в промежуточной коробке незадолго до развертывания. Пользователи в окне разработчика со старыми паролями MD5 могут получить доступ к crontab нормально, а /etc/pam.d/system-auth идентично. Ящики для разработчиков и промежуточные блоки должны быть идентичными, за исключением их IP-адресов. Я подозреваю, что пропустил что-то действительно очевидное и глупое ...

Итак, мой вопрос: как я могу разрешить доступ к crontab для пользователей, которые еще не изменили свои пароли и были хешированы SHA-512? Или как я могу обойти эту проблему?

Мне удалось исправить эти моменты после публикации вопроса.

Получается, что /etc/shadow записи для затронутых пользователей пароля MD5 каким-то образом имели поле после дублирования хешированного пароля, из-за чего PAM не мог интерпретировать строку. Другими словами, плохая работа по вырезанию и вставке.

Мне не хватило кофе ...

У меня тоже была эта проблема, и оказалось, что в / etc / shadow нет записи для этого пользователя. С помощью pwck добавил пользователя, и проблема была решена.

Были такие же проблемы. Если вам не нужен точный пароль для учетной записи, просто запустите:

pwconv