На клиенте запускаем:
journalctl -f
или смотрим сообщения:
sshd sssd
в зависимости от конфигурации ОС.
Затем выполняем конкретную попытку:
ssh user@client01
И связываем события по времени.
Это значительно полезнее, чем читать:
5000 строк старого журнала
и искать там похожее слово denied.
28. SSSD имеет несколько уровней логирования
Если обычного журнала недостаточно, можно временно повысить детализацию SSSD.
Например через:
sssctl debug-level
после чего воспроизвести проблему.
Но debug logging лучше включать для конкретной диагностики, а не оставлять постоянно на максимальном уровне.
Иначе:
больше логов
≠
проще диагностика
Можно получить огромное количество шума.
29. Очень полезно диагностировать сверху вниз
Вместо:
SSH не работает
↓
переустановить ipa-client
строим лестницу доказательств:
DNS работает?
↓
Kerberos работает?
↓
user identity доступна?
↓
SSSD работает?
↓
HBAC разрешает?
↓
PAM разрешает?
↓
sshd разрешает?
↓
session создаётся?
Как только один уровень перестаёт проходить, область поиска резко сужается.
30. Один из сильнейших наборов проверок
Практически можно двигаться так:
dig SRV _kerberos._udp.example.ru
kinit user@EXAMPLE.RU
klist
id user
getent passwd user
sssctl user-checks -a auth -s ssh user
ipa hbactest \ --user=user \ --host=client01.example.ru \ --service=sshd
а затем уже:
ssh user@client01.example.ru
Это не универсальный скрипт диагностики. Но порядок хорошо показывает: какой слой мы проверяем каждой командой.
31. Что означает каждый результат
kinit FAIL
Ищем в первую очередь:
Kerberos DNS time credentials KDC connectivity
kinit OK id user FAIL
Смотрим:
SSSD NSS directory lookup cache
id user OK hbactest DENIED
Смотрим:
HBAC user/group membership host/hostgroup service
hbactest ALLOW ssh DENIED
Смотрим дальше:
PAM sshd local access restrictions authentication method logs
ssh authentication OK session FAIL
Смотрим:
home directory shell permissions PAM session filesystem
Именно такой подход не позволяет смешать пять разных проблем в одну фразу: «FreeIPA не работает».
32. Итог нашего кейса
Исходный симптом:
ipa-client-install → SUCCESS ssh user@client01 → DENIED
После проверки:
DNS → OK Kerberos → OK SSSD → OK NSS → OK HBAC → DENIED
Причина:
client01 не входил в host group, разрешённую HBAC rule
После исправления:
HBAC → ALLOW SSH → SUCCESS
А затем отдельно проверено создание пользовательской сессии и home directory.
Главное
FreeIPA login — это не одна проверка:
user + password
Это цепочка:
DNS ↓ Kerberos ↓ Directory ↓ SSSD ↓ NSS ↓ PAM ↓ HBAC ↓ sshd ↓ session
Поэтому:
ipa-client-install successful
≠
user can log in
kinit successful
≠
SSH allowed
user visible in getent
≠
HBAC allows access
HBAC allows access
≠
local sshd configuration allows access
Правильная диагностика здесь строится не на попытках «починить FreeIPA», а на вопросе:
На каком именно этапе заканчивается подтверждённая работоспособность?
Как только этот этап найден, количество реальных гипотез обычно резко уменьшается.
Нужно подключить Linux-серверы к FreeIPA или разобраться с проблемой доменной аутентификации?
Выполняю развёртывание FreeIPA, подключение Linux-клиентов и диагностику связанных проблем DNS, Kerberos, SSSD и доступа пользователей. Услуги на Kwork
#Кейс #FreeIPA #Linux #SSSD #Kerberos #IAM #Troubleshooting