Проверка аутентификации SSSD и HBAC

Полезный инструмент SSSD:

sssctl user-checks -a auth -s ssh user

Он позволяет проверить пользователя в контексте конкретного PAM service. Это хороший способ разделить:

identity retrieval

и:

authorization/login path

Если:

id user

работает, а:

sssctl user-checks -a auth -s ssh user

показывает проблему, то искать причину в DNS как в первой гипотезе уже менее рационально.

Допустим:

ipa-client-install
→ SUCCESS

Проверяем:

systemctl is-active sssd

active

DNS:

dig SRV _kerberos._udp.example.ru

OK

Kerberos:

kinit user@EXAMPLE.RU

SUCCESS

Identity:

id user

uid=...
groups=...

Но:

ssh user@client01

Permission denied

У нас уже есть важный вывод:

DNS         → OK
Kerberos    → OK
SSSD/NSS    → OK
SSH login   → FAIL

Значит, нет смысла хаотично менять DNS или переустанавливать IPA client. Проверяем следующий слой.

Например:

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

Получаем:

Access granted: False

Теперь проблема локализована. Проверяем HBAC rules. Выясняется:

rule:
infra-admins-to-linux

users:
infra-admins

hosts:
linux-servers

services:
sshd

Но client01 не входит в:

linux-servers

Получаем первопричину: пользователь соответствует правилу, service соответствует правилу, но target host не включён в разрешённую группу.

Плохое решение:

разрешить всем всё

только чтобы вход заработал. Правильнее исправить именно требуемую связь:

client01
    ↓
linux-servers

или создать подходящее HBAC rule в соответствии с принятой моделью доступа. После изменения снова:

ipa hbactest ...

Теперь:

Access granted: True

Но диагностика ещё не закончена.

ssh user@client01.example.ru

Аутентификация проходит. Но появляется следующая проблема:

Could not chdir to home directory

Это уже другая неисправность. Не нужно возвращаться к Kerberos. Мы прошли дальше по цепочке.

FreeIPA может хранить для пользователя путь:

/home/user

Но сама запись:

homeDirectory=/home/user

не создаёт каталог физически на каждом Linux-клиенте. Нужен механизм:

pam_mkhomedir

или другой выбранный способ предоставления home directory. При установке IPA client для этого часто используется:

--mkhomedir

Тогда при первом успешном входе каталог может быть создан автоматически.

Например:

getent passwd user

показывает:

/home/user

Это доказывает: системе известно, какой home directory назначен пользователю. Но:

homeDirectory=/home/user
        ≠
/home/user существует

Проверяем:

ls -ld /home/user

Если каталога нет, проблема уже относится к созданию пользовательской сессии, а не к identity management как таковому.

FreeIPA может вернуть пользователю:

/bin/bash

или:

/bin/sh

Но если настроено:

/sbin/nologin

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

getent passwd user

и смотрим последнее поле. То есть identity information содержит не только UID и группы. Она ещё определяет часть параметров пользовательской среды.

Даже если FreeIPA разрешает вход через HBAC, sshd может иметь собственные ограничения. Например:

AllowUsers
DenyUsers
AllowGroups
DenyGroups
Match

Получаем:

FreeIPA → разрешает
        ↓
sshd → запрещает

И снова никакого противоречия. FreeIPA — не единственный механизм authorization на Linux-хосте.

Например:

sshd -T

А если используются Match-условия, при необходимости проверяем конфигурацию в контексте конкретного пользователя и подключения. Нас интересует: какое правило реально применяется к этой попытке входа? а не: какая строка первой нашлась в конфигурационном файле?