Как исправить ошибки аутентификации PAM на сервере SUSE Linux Enterprise Server

Сообщение «Сбой аутентификации PAM» не всегда означает, что пароль неверный. В SUSE Linux Enterprise Server (SLES) подключаемые модули аутентификации (PAM) образуют стек, который проверяет подлинность, доступ к учетной записи, изменения пароля и настройку сеанса. Сбой может быть вызван опечаткой или отключенной учетной записью, неисправным включением PAM, недоступной службой LDAP или Active Directory, проблемой с часами Kerberos или DNS, или проблемой с сеансом рабочего стола, возникшей после аутентификации.

Наиболее безопасный способ решения проблемы — определить, какая служба и какой этап PAM вышли из строя, прежде чем изменять конфигурацию. В данном руководстве в качестве справочного материала используется документация SUSE Linux Enterprise Server 15 SP7. Если вы используете другой пакет обновлений SLES или специализированный образ виртуальной машины, перед применением команд проверьте соответствующую документацию SUSE и версии установленных пакетов.

Во-первых, что именно выходит из строя: одна служба или все входы в систему?

Запишите имя пользователя, точное время, хост и точку входа, вызвавшую сбой: SSH, локальная текстовая консоль, графический вход suили приложение. По возможности протестируйте с использованием второй известной учетной записи. Если сбой происходит только с SSH, в то время как вход через консоль работает, сосредоточьтесь на /etc/pam.d/sshdслужбе SSH. Если локальные пользователи работают, а пользователи каталога не работают, проверьте SSSD, LDAP, Active Directory, Kerberos, DNS или политику авторизации хоста. Если вход через консоль проходит успешно, но рабочий стол отклоняет пользователя или возвращается к экрану входа в систему, сбой может быть связан с графической сессией или домашним каталогом, а не с аутентификацией по паролю.

Во время устранения неполадок держите открытой существующую корневую оболочку. Если вы подключены удаленно, держите открытой вторую SSH-сессию и убедитесь, что у вас есть доступ к консоли или функции восстановления, прежде чем вносить изменения в PAM. Синтаксическая ошибка или ошибка управляющего флага в общем файле PAM может блокировать новые входы в систему для нескольких служб.

1. Прочитайте дневник, посвященный неудачной попытке.

В руководстве по устранению неполадок SUSE рекомендуется просмотреть системный журнал на наличие сообщений от процесса входа в систему и PAM. Запрос следует выполнить за короткий промежуток времени, близкий к моменту сбоя, чтобы несвязанные сообщения не заслоняли причину:

sudo journalctl -b --since "15 minutes ago"

В случае проблемы, связанной только с SSH, сузьте круг поиска до демона SSH:

sudo journalctl -b -u sshd --since "15 minutes ago"

Проверьте имя службы, имя службы PAM, имя модуля и укажите, относится ли сообщение к auth, account, password, или session. Стек PAM authпроверяет учетные данные; accountпроверяет, разрешен ли пользователю доступ к этой службе; sessionподготавливает пользовательскую среду. Успешная проверка пароля с последующим отказом в доступе к учетной записи указывает на проблему, отличную от неизвестного пользователя или неверного пароля. Избегайте включения подробной отладки в производственной системе, если это не требуется; диагностические журналы могут содержать имена учетных записей и другую конфиденциальную информацию.

Для получения информации о процессе локальной и сетевой аутентификации см. руководство по устранению неполадок SLES от SUSE .

2. Убедитесь, что SLES может найти пользователя.

Перед изменением PAM проверьте, может ли переключатель службы имен системы разрешить имя учетной записи:

getent passwd user_name
id user_name

Замените user_nameна соответствующий логин. Если эти команды не возвращают учетную запись для пользователя каталога, возможно, PAM работает корректно, в то время как поиск идентификатора завершается с ошибкой. Убедитесь, что настроенная служба идентификации запущена, хост может получить доступ к каталогу и пользователю разрешен вход в систему на этом хосте. Для конфигурации на основе SSSD проверьте журналы демона и последние записи:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

В документации SUSE указано, что SSSD предоставляет как интерфейсы NSS, так и PAM, и отмечает возможность кэширования данных идентификации. Если пользователи сообщают о периодических сбоях, сравните время локальной системы и разрешение DNS с каталогом или средой Kerberos. Kerberos зависит от правильной синхронизации времени; наличие работающего сетевого соединения само по себе не гарантирует успешную аутентификацию.

Также проверьте наличие конфликтов имен. SUSE указывает на то, что имя пользователя, существующее локально и в сетевом источнике идентификации, может быть причиной проблем с сетевой аутентификацией. Перед редактированием правил PAM убедитесь, какой источник идентификации должен владеть учетной записью.

3. Проверьте файл службы PAM и общий стек.

SLES хранит файлы PAM для каждой службы в /etc/pam.d. Файл службы, например, /etc/pam.d/sshdобычно включает в себя общие файлы, такие как common-auth, common-account, common-password, и common-session. Некорректная строка в общем файле может повлиять на несколько служб; некорректная строка в файле одного приложения может повлиять только на это приложение.

Перед редактированием прочтите соответствующие файлы и проверьте ссылки в них:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Проверьте наличие орфографических ошибок в названиях модулей, отсутствующих файлов модулей, некорректных параметров, неожиданного порядка и изменений, внесенных во время недавнего развертывания пакета или аутентификации. Флаги управления имеют значение: requiredони регистрируют сбой, но продолжают работу по стеку; requisiteмогут немедленно остановить процесс; sufficientмогут позволить успешному завершению вернуться раньше, если ранее не произошел сбой ни одного необходимого модуля. Не копируйте стек PAM из другого дистрибутива или выпуска SLES, не понимая его модули и поток управления.

Прежде чем что-либо менять, создайте резервную копию текущего каталога, доступную только для прав root, сохранив при этом символические ссылки:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Убедитесь в наличии резервной копии и точно запишите, какие файлы вы изменили. Если доступ заблокирован для всех пользователей, используйте поддерживаемую процедуру восстановления SLES и восстановите систему из заведомо исправной конфигурации, вместо того чтобы импровизировать при входе в систему.

4. В SLES проверьте, управляет ли pam-config общими файлами.

SUSE предоставляет pam-configвозможность поддерживать глобальные PAM-файлы и поддерживаемые конфигурации приложений. В целом, это безопаснее, чем ручное редактирование сгенерированных разделяемых стеков при добавлении или удалении поддерживаемого метода. Сначала изучите доступные модули и текущую интеграцию с SSSD:

sudo pam-config --list-modules
sudo pam-config --query --sss

Если сервер намеренно использует SSSD и интеграция отсутствует, в документации SUSE sudo pam-config --add --sssописан способ её добавления. Делайте это только после подтверждения архитектуры аутентификации каталогов, проверки текущего стека, создания резервной копии и обеспечения возможности восстановления. Не используйте это как универсальное решение для каждой «ошибки аутентификации». Повторно проверьте конфигурацию и протестируйте во второй сессии.

Особенно рискованная команда — это ` pam-config --create.`. SUSE утверждает, что она генерирует простую конфигурацию аутентификации Unix и перезаписывает существующие файлы конфигурации, которые не поддерживаются pam-config(при этом сохраняя резервные копии с .pam-config-backupсуффиксом). Это не стандартное решение для исправления одной неудачной попытки входа в систему. Используйте её только в том случае, если вы намеренно планируете восстановить конфигурацию и у вас есть запланированное восстановление.

Если в вашей организации файлы PAM намеренно поддерживаются вручную, последовательно придерживайтесь этого подхода. SUSE отмечает, что ручная настройка требует отключения pam-configэтих файлов. Пользовательские стеки должны сохранять необходимые модули сеансов, в том числе pam_systemd.soв качестве необязательного модуля сеанса, где это применимо.

5. Разделите проблемы SSH, каталогов и рабочего стола.

Если только SSH отклоняет учетную запись.

Сравните /etc/pam.d/sshdс заведомо исправной конфигурацией SLES и изучите журнал демона SSH в момент неудачной попытки входа. Убедитесь, что учетная запись разрешена собственными настройками SSH и средствами контроля доступа, а также PAM. Не ослабляйте аутентификацию SSH и не удаляйте проверки учетных записей только для того, чтобы ошибка исчезла.

Если не работают только пользователи каталога

Подтвердите поиск учетной записи с помощью команды `sudo apt install getentSSSD`, проверьте состояние и журналы SSSD, а также убедитесь в доступности каталога, DNS, синхронизации времени, регистрации хоста и политике доступа пользователей. Если другой пользователь каталога успешно выполнил команду `sudo apt install SSSD`, сравните группы, оболочку, домашний каталог и правила доступа, специфичные для хоста, затронутой учетной записи. В руководстве по клиенту аутентификации SUSE описан SSSD, управляемый YaST, и его проверки состояния.

Если вход через консоль работает, но графический сеанс завершается с ошибкой,

Проверьте графический вход в систему и журналы сеансов, доступность домашнего каталога, права собственности, свободное место на диске и любые шаги по разблокировке зашифрованного домашнего каталога. Успешный вход в систему через текстовую консоль является полезным доказательством того, что пароль и путь базовой аутентификации работают; это переключает внимание на сеанс рабочего стола или пользовательскую среду. Избегайте удаления пользовательских файлов в качестве первого шага. Руководство по устранению неполадок SUSE рекомендует методично выявлять проблемы с конфигурацией рабочего стола.

6. Проверьте качество ремонта, не рискуя блокировкой устройства.

После внесения изменений откройте новую тестовую сессию, пока оболочка восстановления остается доступной. Протестируйте затронутую службу с помощью затронутой учетной записи, затем протестируйте вторую учетную запись и локального администратора. Для аутентификации в каталоге подтвердите поиск учетной записи и работоспособность службы, а также успешный вход в систему. Еще раз проверьте журнал на наличие новых ошибок PAM и удалите все временные параметры отладки с помощью соответствующего pam-config --deleteпараметра после завершения тестирования.

Наконец, убедитесь, что результат устраняет проблему на этапе сбоя, а не скрывает её. Исправленный вход в систему должен аутентифицировать предполагаемого пользователя, обеспечивать соблюдение предполагаемой политики учетной записи и создавать обычную сессию. Сохраните резервную копию до тех пор, пока не проверите эти результаты и не задокументируете окончательную конфигурацию.

Когда следует остановиться и включить аварийный режим?

Прекратите вносить удаленные изменения, если потерян доступ с правами root, одновременно отказало несколько служб, был перезаписан общий стек аутентификации или вы не можете определить, какому менеджеру конфигурации принадлежат файлы. В документации SLES описано использование доступа с правами root для восстановления конфигурации и перехода в режим восстановления, когда обычный вход в систему недоступен. Для управляемых производственных систем перед перестройкой общего стека аутентификации следует обратиться к команде по управлению идентификацией или платформой.

Для получения точной информации о структуре PAM-файлов, флагах модулей, поведении и шагах восстановления используйте руководство SUSE SLES 15 SP7 PAM,pam-config соответствующее версии системы , и руководство SUSE по распространенным проблемам . PAM-стеки представляют собой политику безопасности; внесите минимальное обоснованное изменение, а затем проверьте как доступ, так и ограничения.