Где бы взять конфиг sshd подходящий для TACACS+?

Question

[Вова]

Всем привет!
Устал бороться с TACACS+.
Что пытаюсь сделать:
* Сервер - сделан руками ИИшки, работает, крутится на виртуальной машине с Линуксом.
* Клиент - взял pam_tacplus.so, "подложил" в свой Линукс, допилил /etc/pam.d/sshd путём добавления трёх строк отсюда:

auth  required pam_tacplus.so server=192.168.0.1 secret=testkey123

Сейчас строка осталась одна, ибо строки про session и account вроде бы не нужны (изначально и они были).

Запускаю Линукс, подключаюсь к нему через ssh (который запускаю в виндовой консоли), ввожу пароль...
(...а ано - ажамбех пашамбе эшельбе шайтанама!)
Судя по логам, всё ок, авторизация прошла. Судя по консоли - disconnect.

В общем, если у вас вдруг есть под руками тот самый файлик sshd из папки /etc/pam.d/ - покажите его, пожалуйста! :) А то у меня уже мозг вскипел.

ЗЫ: Техническических подробностей как бы и нет. Линукс собирается с помощью buildroot и накатывается на одноплатник. Правок, относящихся к авторизации - минимум. В конфиге включен флажок UsePAM в состояние yes, в результате чего в "прошивке" образуется, собственно pam_tacplus.so. В файл sshd добавлена одна строка из начала сего текста. Все три строки из документации тоже пробовал вписать, с тем же результатом. Байтики по сети бегают, логи пишутся, слова а-ля AUTH SUCCESS видны, но логина по ssh не случается (в консоли появляется надпись disconnect и на этом всё). Единственная говорящая ошибка (и она же последняя), которую я вижу в логах выглядит вот так:

Sep 23 10:48:32 olt auth.crit sshd[357]: fatal: PAM: pam_setcred(): Failure setting user credentials

Такое ощущение, что ломается даже не процесс логина, а попытка запустить что-то после логина (честно, не очень понимаю, что делает Линукс после ввода пароля, но наверное запускает bash, создаёт home или что-то такое).
Странность в OpenSSH (от которого, вроде бы, зависит PAM) я нашёл. Он слал вместо пароля INCORRECT. Чтобы этого не происходило, пришлось в /etc/passw добавить пользователя с именем, совпадающем с именем на сервере TACACS.
(Процесс логина в одноплатник происходит из консоли виндовой машины по ssh).
Логи разные снимал, в DeepSeek запихивал, ничего не нашёл. (логов МНОГО и непонятно, что из них вообще имеет смысл сюда копипастить).

В общем, покажите, пжл, свой файлик sshd, подходящий для работы с TACACS+ :)

ЗЗЫ: Мой файлик sshd на данный момент выглядит как-то так (и он не работает):

auth		required	pam_nologin.so
auth		sufficient	pam_tacplus.so	debug	 server=192.168.0.1 secret=TestSecret
auth		sufficient	pam_unix.so		debug	 nullok
auth		required	pam_deny.so		debug

Предполагается, что если залогинится через TACACS не удастся, то будет произведена попытка залогинится локально (каким-нибудь root).

ЗЗЗЫ: То есть, в процессе участвуют три машинки: одноплатник с Линуксом, виндовая машина с ssh клиентом, и Линукс с TACACS сервером в виртуалке и "базой данных пользователей".

Comments

[Довольный Айтишникъ]

А если вот так?

auth       sufficient   pam_tacplus.so debug server=192.168.0.1 secret=TestSecret
auth       sufficient   pam_unix.so debug nullok
auth       required     pam_deny.so
account    required     pam_unix.so
session    required     pam_unix.so

[Довольный Айтишникъ]

Ну и подключение запустить с максимальным уровнем отладки
ssh -vvv user@192.168.x.x
и поделиться результатами. Желательно как со стандартным вариантом, так и с предложенным выше

[Zerg89]

Логинитесь рутом? Если да в ssh дожолжно быть настроено разрешение permitrootlogin yes

Проверте файл etc/nologin или var/run/nologin если он есть никого кроме root непустит

session required pam_unix.so нужен хотябы для отладки без него в логи не попадает сам вход и выход из сессии

sufficient проверяет только предидушие и если он пройден и все предидущие цепочка прерывается

sufficient — если этот модуль сработал успешно (и ни один required до него не упал с ошибкой), PAM сразу считает весь стек успешно пройдеными и игнорирует оставшиеся ниже модули.

Так будет чтото в логах
auth required pam_nologin.so
session required pam_unix.so debug nullok
auth sufficient pam_tacplus.so debug server=192.168.0.1 secret=TestSecret
auth required pam_deny.so debug

Ps home/user тоже может быть проблема
Проблема с правами доступа к системным файлам (pam_localuser или pam_limits)При входе SSH-демон пытается применить лимиты (pam_limits.so) и проверить файлы конфигурации пользователя.В чём проблема: Ошибка возникает, если повреждены права на критически важные файлы, например /etc/shadow, /etc/passwd, домашнюю директорию пользователя или каталог .ssh. Если служба sshd (или дочерний процесс) из-за жестких правил SELinux/AppArmor или некорректных прав на файлы (chmod) не может прочитать данные пользователя, pam_setcred() завершится ошибкой.Как исправить: Проверьте, что права на домашнюю папку пользователя установлены как 700, а на файл .ssh/authorized_keys — 600. Убедитесь, что владелец этих папок — сам пользователь.

Так что session required pam_mkhomedir.so skel=/etc/skel umask=0077 для проверки тоже можно вернуть

[Zerg89]

# === СТЭК АУТЕНТИФИКАЦИИ (AUTH) ===
auth required pam_nologin.so
auth sufficient pam_tacplus.so debug server=192.168.0.1 secret=TestSecret
auth required pam_unix.so nullok
auth required pam_deny.so

# === СТЭК УЧЕТНЫХ ЗАПИСЕЙ (ACCOUNT) ===
account required pam_nologin.so
account required pam_unix.so
account sufficient pam_tacplus.so debug
# в последней строчке если глючит возможно сделать опциональным
#account optional pam_tacplus.so debug

# === СТЭК УПРАВЛЕНИЯ СЕССИЯМИ (SESSION) ===
session required pam_env.so
session required pam_limits.so
session optional pam_mkhomedir.so skel=/etc/skel umask=0077
session required pam_unix.so
session optional pam_tacplus.so debug

Ps Особенность реализации в pam_tacplusВ отличие от таких модулей, как pam_unix.so (который берет данные из /etc/shadow) или pam_krb5.so (получает Kerberos-билеты), протокол TACACS+ по своей природе не имеет встроенного понятия "Unix-credentials" (UID, GID, домашняя директория). TACACS+ изначально создавался для сетевого оборудования (Cisco и др.) и оперирует уровнями привилегий (priv-lvl) и разрешенными командами.Поэтому в большинстве стандартных реализаций модуля pam_tacplus функция pam_sm_setcred() работает по упрощенной схеме:Она не выполняет никаких сетевых запросов к серверу TACACS+ (все проверки авторизации и аккаунтинга происходят на этапах account и session).Её главная задача — просто вернуть статус PAM_SUCCESS (успешно), чтобы не заблокировать продвижение по стеку PAM.Если локальный пользователь с таким же именем существует в системе Linux, PAM позволяет приложению sshd назначить ему стандартные локальные UID/GID.

[Вова]

Довольный Айтишникъ, "А если вот так?" - не помогло! :)

[Вова]

Zerg89, Так это, root то работает :) Флажки попробовал, спасибо, жаль не помогло.

Answer 1

[Вова]

KbdInteractiveAuthentication := yes помогает

Answer 2

[Пума Тайланд]

pam_sm_setcred в pam_tacplus — заглушка, всегда PAM_SUCCESS. А у pam_deny эта же функция явно возвращает PAM_CRED_ERR, и это единственный модуль в твоём auth-стеке, способный так зафейлить: sshd после аутентификации гоняет pam_setcred по всему стеку заново, не только по модулю что тебя пустил. Подними отдельный sshd с полной отладкой на левом порту: /usr/sbin/sshd -D -ddd -e -p 2222, подключись туда и смотри что творится вокруг credentials establishing живьём. Если виноват deny, он там лишний: required в конце после sufficient-цепочки обычно не нужен.

Comments

[Вова]

/usr/sbin/sshd -D -ddd -e -p 2222

Спасибо, помогло. После этого вызова образовались логи, логи были показаны коллеге, коллега помедетировал 5 минут и сказал потыкать флажок KbdInteractiveAuthentication. И вуаля! Всё заработало. (Удивительно, что килобайты предыдущих логов такого эффекта не дали).