Проверяем SSSD, PAM, HBAC и SSH

Начинаем с очевидного:

systemctl status sssd

Но мы уже знаем:

active (running)
        ≠
SSSD корректно получает данные

Поэтому полезнее проверить сам результат. Например:

sssctl domain-status example.ru

или соответствующий домен клиента. Далее:

sssctl user-checks user

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

/etc/sssd/sssd.conf

и конфигурацию IPA-клиента.

9. Не забываем про cache

SSSD активно использует кэш. Это полезно:

FreeIPA временно недоступна
        ↓
часть identity information
может оставаться локально

Но при диагностике кэш иногда мешает. Например:

• — пользователь недавно добавлен в группу;
• — HBAC rule изменена;
• — атрибуты пользователя обновлены;
• — исправлена конфигурация.

А клиент продолжает использовать старое состояние. Тогда полезно понимать:

мы видим актуальные данные
или кэшированные?

Для конкретного пользователя можно очистить устаревшую запись контролируемым способом через sssctl, а затем повторить проверку. Главное — не превращать очистку всего кэша SSSD в универсальное решение каждой проблемы.

10. Допустим, id user работает

Теперь мы уже знаем:

FreeIPA directory
        ↓
SSSD
        ↓
NSS
        ↓
Linux видит пользователя

И отдельно:

kinit
→ работает

То есть identity и Kerberos подтверждены. Но SSH всё ещё отвечает:

Permission denied

Теперь область поиска стала существенно меньше.

11. Проверяем PAM

sshd не реализует всю пользовательскую аутентификацию самостоятельно. В типовой конфигурации он взаимодействует с PAM — Pluggable Authentication Modules. Упрощённо:

sshd
 ↓
PAM
 ↓
pam_sss
 ↓
SSSD

Поэтому нужно проверить, что SSH действительно использует PAM. Например:

sshd -T | grep usepam

Ожидаем:

usepam yes

Но одной строки снова недостаточно. Нужно учитывать фактическую PAM-конфигурацию системы.

12. PasswordAuthentication и KeyboardInteractiveAuthentication — тоже имеют значение

Представим:

Kerberos
SSSD
PAM
→ полностью исправны

Но в sshd_config установлен режим, при котором нужный способ аутентификации не разрешён. Например, конфигурация SSH может включать или выключать:

PasswordAuthentication
KbdInteractiveAuthentication
UsePAM

И их фактическое сочетание зависит от выбранной модели входа. Поэтому при диагностике важно смотреть не только файл:

/etc/ssh/sshd_config

но и итоговую конфигурацию:

sshd -T

Потому что:

строка в одном config file
        ≠
итоговое значение sshd

Конфигурация может включать дополнительные файлы и Match-блоки.

13. Теперь переходим к HBAC

HBAC — Host-Based Access Control. Это механизм FreeIPA, который отвечает примерно на вопрос: может ли этот пользователь использовать этот service на этом host? Логика содержит три ключевых объекта:

USER
  +
HOST
  +
SERVICE

Например:

user:
alice

host:
web01.example.ru

service:
sshd

Если подходящая HBAC rule разрешает эту комбинацию — доступ возможен. Если нет — пользователь может быть совершенно корректным доменным пользователем с правильным паролем и рабочим Kerberos, но вход будет запрещён.

14. Это хороший пример различия authentication и authorization

Получаем:

kinit alice
→ SUCCESS

но:

ssh alice@web01
→ DENIED

Противоречия нет. Первое доказало:

alice успешно authenticated

Второе затрагивает:

можно ли alice использовать sshd
на web01?

То есть authorization.

15. HBAC можно проверить до реального SSH

Для этого есть:

ipa hbactest

Например:

ipa hbactest \
  --user=alice \
  --host=web01.example.ru \
  --service=sshd

Результат:

Access granted: True

или:

Access granted: False

Это очень полезная проверка. Вместо: «Наверное, проблема в HBAC» мы можем проверить конкретную комбинацию:

user + host + service

16. Но проверяйте именно тот service, который реально используется

Для SSH это обычно:

sshd

То есть правило вида:

alice
+
web01
+
login

не обязательно разрешает:

alice
+
web01
+
sshd

Если service не тот, правило может выглядеть логично в интерфейсе, но не применяться к реальной попытке входа.