Диагностика сбоев входа в SLES PAM без блокировки доступа.

Сообщение «Сбой аутентификации PAM» не указывает на универсальное решение. Сначала определите, какая служба и какие пользователи не работают, затем проверьте журнал в соответствующее время. В SUSE Linux Enterprise Server (SLES) подтвержденную глобальную проблему PAM следует устранять с помощью команды `push` pam-config, а файл отдельной службы следует изменять только в том случае, если неисправен её собственный стек. Во время тестирования держите открытой рабочую сессию root или администратора; неисправный стек PAM может блокировать новые входы по SSH и консоли.

В текущем руководстве по безопасности и усилению защиты SLES 15 SP7 модуль PAM описывается как набор модулей аутентификации, учетных записей, паролей и сессий. Это различие имеет значение: правильный пароль может пройти authэтап проверки, но быть отклонен позже политикой учетных записей или правилом, специфичным для службы. Одного лишь общего сообщения об ошибке недостаточно, чтобы определить, какой именно этап завершился неудачей.

Что доказывает эта ошибка, и что она не доказывает?

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

Подтверждено: документированный стек SSH от SUSE включает в себя pam_nologin.soобщие файлы PAM. Если /etc/nologinтакой модуль существует, он запрещает вход в систему пользователям, кроме root. Зависит от контекста: локально отредактированные правила, службы каталогов и сторонние модули многофакторной аутентификации могут добавлять дополнительные проверки. Не определяется только сообщением: что пароль неверный, файлы PAM повреждены или учетная запись заблокирована. Начните с анализа затронутой службы и ее журнала, а не с замены стека.

Какой путь авторизации не работает?

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

sudo journalctl -e

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

Если проблема только с SSH, проверьте журнал демона SSH:

sudo journalctl -u sshd

Затем сравните пути доступа. Если пользователь может пройти аутентификацию на локальной консоли, но не через SSH, сосредоточьтесь на /etc/pam.d/sshdполитике доступа SSH или модуле, специфичном для SSH. Если несколько служб отклоняют одних и тех же локальных пользователей, проверьте их общие common-*файлы. Если не удается аутентифицировать только одного пользователя, проверьте состояние учетной записи и пароль, прежде чем изменять общесистемную аутентификацию.

Это локальная учетная запись или сетевая?

Для локального пользователя сначала проверьте имя пользователя, раскладку клавиатуры и клавишу Caps Lock. Если требуется сброс учетных данных, используйте одобренный администратором инструмент для сброса паролей, например YaST User and Group Management, вместо редактирования /etc/shadowвручную. Если доступ по SSH запрещен для всех пользователей, кроме root, /etc/nologinперед изменением PAM проверьте наличие файла планового обслуживания, например; удаляйте его только в том случае, если подтверждено, что блок обслуживания устарел, и у вас есть соответствующие права.

Для пользователей, использующих LDAP, Active Directory или другую систему управления учетными записями, наличие рабочего пароля на другом сервере не доказывает, что данный хост SLES может связаться с поставщиком идентификации. SUSE перечисляет среди возможных причин проблемы с сетью и DNS, расхождение во времени Kerberos, неправильно настроенные правила PAM, политику доступа к хосту и недоступные домашние каталоги. Проверьте, может ли другой пользователь домена войти в систему и может ли затронутый пользователь войти в систему на другом хосте. Затем проверьте настроенную службу идентификации и подключение к серверу.

Если хост использует SSSD, проверьте, подключена ли к нему служба и настроен ли PAM для её использования:

systemctl status sssd
sudo pam-config --query --sss

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

Как следует устранить подтвержденную проблему с конфигурацией PAM?

Проверьте файл, относящийся к конкретной службе, и содержащиеся в нем общие правила:

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

В SLES pam-configглобальные файлы хранятся в папке /etc/pam.d/common-*; отдельные файлы служб, такие как , /etc/pam.d/sshdхранятся отдельно. Не редактируйте сгенерированные общие файлы вручную, если вы специально не отключили pam-configдля них эту функцию. Если вы подтвердите, что этот хост должен использовать SSSD, и в нем отсутствуют правила PAM для SSSD, обратитесь к документации SUSE sudo pam-config --add --sssпо их добавлению. Используйте его только после подтверждения того, что сам SSSD настроен и работает, затем протестируйте новый вход в систему, пока открыта рабочая административная сессия.

Распространенное, но опасное заблуждение заключается в том, что pam-config --createэто безобидная команда восстановления. SUSE утверждает, что она создает базовую конфигурацию аутентификации Unix и перезаписывает существующие файлы, которыми не управляет, сохраняя резервные копии. Это может привести к удалению пользовательской многофакторной аутентификации или аутентификации по каталогу. Не запускайте ее в качестве общего шага восстановления. В случае опечатки в файле службы восстановите заведомо работоспособную конфигурацию этой службы, соответствующую версии, из надежной резервной копии или измените конкретную ошибочную строку в соответствии с процедурой внесения изменений в вашей организации.

Как можно подтвердить факт ремонта?

Оставьте открытой исходную сессию root или администратора. Запустите вторую сессию через ту же службу, которая дала сбой, например, новое SSH-соединение, и проверьте затронутую учетную запись. Убедитесь, что в журнале больше не регистрируется тот же отказ PAM и что другой настроенный метод аутентификации по-прежнему работает. Если сбой продолжается, зафиксируйте точную метку времени, службу, имя модуля PAM и соответствующие очищенные строки журнала; эти сведения более полезны, чем общее сообщение «сбой аутентификации».

Официальные ссылки

• Руководство по администрированию SUSE SLES 15 SP7: Распространенные проблемы и их решения — устранение неполадок при локальном и сетевом входе в систему.
• Руководство по безопасности и усилению защиты SUSE SLES 15 SP7: аутентификация с помощью PAM — этапы PAM, стек SSH и pam-configт. д.
• SUSE SLES 15 SP7: Настройка клиентов аутентификации с использованием YaST — состояние SSSD и поведение кэша.
• SUSE SLES 15 SP7: Обеспечение безопасности сетевых операций с помощью OpenSSH — просмотр сообщений журнала sshd.