Я хочу иметь возможность передавать ssh с хоста FreeBSD на хост FreeBSD, используя свой билет Kerberos, сгенерированный при первом входе в систему.
FreeBSD 10.3 с работающим openldap-sasl-client, kerberos 5 (не heimdal), sssd, ssh и присоединен к Active Directory (2008 R2). Мне пришлось скомпилировать sssd из исходного местоположения / usr / ports, потому что по умолчанию sssd-ad не включен, что мне нужно. Я не использую winbind, поэтому ссылка 1 мне не поможет. (Очевидно, во FreeBSD нет команды authconfig.) Я могу выполнить kinit просто хорошо:
[bgstack15@localhost /]$ kinit
bgstack15@EXAMPLE.COM's Password:
[bgstack15@localhost /]$ klist
Credentials cache: FILE:/tmp/krb5cc_5532829429
Principal: bgstack15@EXAMPLE.COM
Issued Expires Principal
Aug 18 16:01:16 2016 Aug 19 02:01:16 2016 krbtgt/EXAMPLE.COM@EXAMPLE.COM
После этого я могу ssh -K secondhost и это приводит меня прямо туда.
Проблема в том, что я хочу иметь возможность сгенерировать билет Kerberos при входе в систему или, по крайней мере, чтобы мне вообще не нужно было вводить свой пароль. Я использовал GSSAPI auth, чтобы попасть на localhost, поэтому я получил билет Kerberos. Могу я передать это, возможно?
Вот мой /etc/pam.d/sshd
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
auth sufficient pam_unix.so no_warn
auth sufficient pam_krb5.so no_warn use_first_pass forwardable ccache=krb5cc_%u
auth required pam_unix.so no_warn try_first_pass
account required pam_nologin.so
account required pam_login_access.so
account sufficient /usr/local/lib/pam_sss.so ignore_unknown_user
account required pam_unix.so
session optional /usr/local/lib/pam_sss.so
session required /usr/local/lib/pam_mkhomedir.so mode=0700
session required pam_permit.so
password sufficient /usr/local/lib/pam_sss.so use_authtok
password sufficient pam_krb5.so use_authtok forwardable
password required pam_unix.so no_warn try_first_pass
Я тоже пробовал
auth sufficient pam_krb5.so no_warn try_first_pass forwardable ccache=krb5cc_%u
Есть возможность просто запустить kinit в .profile, но я стараюсь не вводить пароль.
Можно ли использовать pam_exec.so? я могу сделать echo PASSWORD | kinit --password-file=STDIN который работает, так можно ли это как-то назвать?
Редактировать:
Учитывая, что вход с паролем вам не помог (в комментариях), возможно, вам придется подправить свой /etc/krb5.conf настройки тоже. Вам нужно заставить это работать с интерактивным входом, прежде чем переходить к устранению неполадок входа GSSAPI.
[libdefaults]
default_realm = EXAMPLE.COM
# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
Оригинальный ответ следует.
Проблема в том, что я хочу иметь возможность сгенерировать билет Kerberos при входе в систему или, по крайней мере, мне вообще не нужно вводить свой пароль. Я использовал GSSAPI auth, чтобы попасть на localhost, поэтому я получил билет Kerberos. Могу я передать это, возможно?
Я подозреваю, что это твоя проблема. Когда вы аутентифицируетесь sshd с GSSAPI (или любой другой формой аутентификации на основе ключей) вы обойдете auth полностью укладываются. Это не позволяет модулям PAM запрашивать у вас любую форму интерактивных учетных данных, но также предотвращает запуск любых «удобных функций», которые ваш модуль реализовал в этом стеке. Быстрый тест - войти в систему с вашим паролем и запустить klist, который, как я очень подозреваю, покажет вам результат, которого вы ожидали.
В pam_krb5 реализация, с которой у меня больше всего опыта, размещена на eyrie.org (Расс Олбери), поэтому я собираюсь использовать его для сравнения с документацией, на которую вы ссылаетесь. Вы можете найти страницу руководства, которую я цитирую Вот.
Оба модуля реализуют pam_setcred() в auth стек:
Компонент аутентификации Kerberos 5 предоставляет функции для проверки личности пользователя (pam_sm_authenticate ()) и установки учетных данных пользователя (pam_sm_setcred ()).
Предоставляет реализации pam_authenticate () и pam_setcred (). Первый берет имя пользователя из сеанса PAM, запрашивает пароль пользователя (если не настроен на использование уже введенного пароля), а затем выполняет первоначальную аутентификацию Kerberos, сохраняя полученные учетные данные (в случае успеха) во временном кэше билетов. Последний, в зависимости от флагов, с которыми он вызывается, либо берет содержимое временного кеша билетов и записывает его в постоянный кеш билетов, принадлежащий пользователю, либо использует временный кеш билетов для обновления существующего кеша билетов пользователя.
Ни один из модулей не реализует pam_setcred() в account стек:
Компонент управления учетными записями Kerberos 5 предоставляет функцию для управления учетными записями pam_sm_acct_mgmt (). Функция проверяет, разрешено ли аутентифицированному участнику войти в локальную учетную запись пользователя, вызывая krb5_kuserok () (который проверяет файл пользователя .k5login).
Предоставляет реализацию pam_acct_mgmt (). Все, что он делает, это выполняет ту же проверку авторизации, что и реализация pam_authenticate (), описанная выше.
Модуль Russ Allbery реализует pam_setcred() в session стек. Модуль FreeBSD делает ничего при вызове session стек.
Компонент управления сеансами Kerberos 5 предоставляет функции для инициирования (pam_sm_open_session ()) и завершения (pam_sm_close_session ()) сеансов. Поскольку управление сеансом не определено в Kerberos 5, обе эти функции просто возвращают успех. Они предоставляются только из-за соглашений об именах для модулей PAM.
Предоставляет реализации pam_open_session (), что эквивалентно вызову pam_setcred () с флагом PAM_ESTABLISH_CRED, и pam_close_session (), который уничтожает кеш билетов, созданный pam_setcred ().
Короче говоря, вам нужен модуль PAM, который будет обеспечивать желаемую функциональность в account или session стеки. Похоже, ваш текущий не сможет удовлетворить эту потребность при аутентификации через GSSAPI.
Кажется, что ваш ssh-клиент (PuTTY) не делегирует учетные данные. Никакие уловки pam не помогут обойти это, не заставив вас повторно ввести свой пароль, что скорее нарушит суть дела.
Кажется, я не могу сделать делегат putty 0.67, даже если выбран вариант. Строка accept, о которой вы говорите, выглядит как логирование аутентификации из sshd, а не делегирование. По умолчанию sshd не регистрирует делегирование. Глядя на журнал пакетов SSH, putty 0.67, похоже, даже не пытается.