что такое в SSH gssapi-keyex, gssapi-with-mic?
простыми словами.
gssapi-with-mic по гуглу это вроде авторизация по маку? без поролей просто мак проверяется и все?
Regacar ★
23.06.22 13:58:15 MSK
это в микрофон говоришь «пусти» и оно пускает.
thesis ★★★★★
( 23.06.22 16:24:24 MSK )
Нет, это аутентификация и через GSS API. GSS API — это такой промежуточный слой, который предполагалось использовать, чтобы из приложения было не важно, какая внизу система аутентификации. На практике внизу почти в 100% случаев находится Kerberos.
Можно сказать, что в случае SSH, GSS API — это способ сделать SSO с Kerberos.
gssapi-keyex и gssapi-with-mic — варианты реализации, отличающиеся деталями протокола, но я почти уверен, что тебе это не важно.
ivlad ★★★★★
( 23.06.22 16:55:46 MSK )
Последнее исправление: ivlad 23.06.22 16:56:46 MSK (всего исправлений: 1)
Ответ на: комментарий от ivlad 23.06.22 16:55:46 MSK
Насколько я понимаю, gssapi-keyex — это не аутентификация, а обмен ключами через GSS API.
Т.е. вместо того, чтобы лазить в .ssh/known_hosts, сверять fingerprint (спрашивая пользователя при необходимости), можно безопасно обменяться ключами через GSS API.
GSSAPI и Firefox/Thunderbird для сквозной авторизации в Windows
Для редактирования principial’ов вам потребуеться Windows Support tools и утилита setspn.exe. Что бы добавить новый SPN вам нужно будет ввести setspn -A HTTP/FQDN имя_машины_для_которой_создаем SPN, где FQDN адресс вашего IIS-сервера.
Вы так же можете посмотреть список всех SPN, setspn -L имя_машины. Стоит обратить внимание, чтобы вы обращались именно по адресу FQDN иначе Kerberos не найдет SPN, регистр букв важен. Или вы можете это сделать вручную используя любой редактор LDAP, adsiedit.msc, AD explorer, ldap admin и т.п. Просто найдите объект компьютера для которого вы хотите создать SPN, CN=SERVER,OU=Domain Controllers,DC=inblock,DC=local и в его атрибутах вы найдете servicePrincipalName.
В случае с Thunderbird’ом вам лишь нужно указать галку «use secure authentication» поле User name не требуеться. На данный момент Firefox и Thunderbird, не показывают никаких ошибок в том случае если Kerberos билет не удалось получить по каким либо причинам, например из-за отсуствия SPN. Поэтому проверить можно только используя снифер, например Wireshark.
Windows использует SSPI закрытый аналог GSSAPI, но смысл имеет одинаковый поэтому я его везде называю GSSAPI.
У вас есть почтовый сервер на UNIX машине? Создайте в AD учетную запись пользователя(пароль не важен) с именем UNIX машины. Используя утилиту ktpass из набора support tools, создадим keytab файл. ktpass -princ imap/debian.inblock.local@inblock.local -mapuser debian +rndpass -ptype KRB5_NT_SRV_HST -out imap.keytab. На UNIX машине не забываем указать DNS сервер домен контроллера. В /etc/krb5.conf
[libdefaults]
default_realm = INBLOCK.LOCAL
И проверерим что у нас корректное FQDN имя у машины — hostname -f. Остаеться только настроить сам сервер на использование GSSAPI вот например инструкция для Dovecot, она заключаеться только во включении этого режима.
GSSAPI, WTF?!
GSSAPI это набор интерфейсов которые задают стандартный набор функции — запросить билет, продлить билет и т.п. GSSAPI являеться посредником между Программой и KDC сервером ну или kerberos протоколом проще говоря.
Он был разработан, чтобы навести порядок т.к. когда он появился существовали разные реализации Kerberos (как и сейчас, MIT и Heimdal) они были несовместимы с друг другом. GSSAPI может использован не только для Kerberos, хотя это самое популярное использование его. Допустим Microsoft разработает новый UltraMegaMSsecure protocol и добавляет ему механизмы вызова через GSSAPI(SSPI), любая программа которая умеет работать с GSSAPI сможет использовать этот новый протокол. Это позволяет избавить разработчика программы во первых понимать как работет авторизация, а во вторых его программа будет работать даже если выйдет новая версия Kerberos10 ;).
К примеру именно через GSSAPI(SSPI) Firefox использует NTLM авторизацию.
Авторизация пользователей в Django через GSSAPI и делегация прав пользователя серверу
Недавно нам с коллегами понадобилось реализовать прозрачную (SSO) авторизацию в нашем проекте. Сейчас довольно мало информации по теме особенно на русском языке. По этой причине решено было поделиться с потомками реализацией подобного функционала.
Итак задача заключалась в следующем: необходимо было настроить прозрачную авторизацию через GSSAPI от пользователя на сервер, а так же иметь потом возможность от имени этого пользователя ходить в БД.
У нас имелось:
- настроенный сервер Kerberos+LDAP
- сервер PostgreSQL, настроенный на авторизацию исключительно по GSSAPI
- сервер приложения Django+UWSGI+nginx, с настроенным Kerberos
Далее нами были предприняты попытки найти что-то стоящее на просторах интернета. Они увенчались относительным успехом, были найдены следующие пакеты для Django: django-kerberos, django-auth-spnego, django-auth-kerbero. По сути все эти пакеты делали одно и тоже, некоторые не обновлялись уже давно и пришлось долго «танцевать с бубном», что бы хоть что то заработало. Они предоставляли такой же функционал как и связка nginx(GSSAPI)+Django(RemouteUser). Все они помогли прийти к решению проблемы своим исходным кодом.
Далее были найдены следующие пакеты для работы с GSSAPI в Python: ccs-pykerberos и python-gssapi, по сути они импортируют реализацию стандарта RFC2744 и RFC4559 в Python. С помощью пакета ccs-pykerberos у нас как раз и получилось реализовать задуманный функционал, далее я покажу немного кода, где реализуется общение с LDAP`ом и пользователем, а так же запрос в БД от его имени.
from django.shortcuts import render from django.template.response import TemplateResponse import kerberos import psycopg2 def index(request): if 'HTTP_AUTHORIZATION' in request.META: kind, initial_client_token = request.META['HTTP_AUTHORIZATION'].split(' ', 1) if kind == 'Negotiate': service = 'HTTP@django-server-pricipal.che.ru' _ignore_result, krb_context = kerberos.authGSSServerInit(service) kerberos.authGSSServerStep(krb_context, initial_client_token) principal = kerberos.authGSSServerUserName(krb_context) _ignore_result = kerberos.authGSSServerStoreDelegate(krb_context) conn = psycopg2.connect( host='postgresql-server-host', user=principal, dbname='request-db', ) cursor = conn.cursor() cursor.execute("SELECT version()") records = cursor.fetchall() else: unauthorized_template_name = 'gssapi_test/unauthorized.html' response = TemplateResponse(request, 'gssapi_test/index.html', status=401) response['WWW-Authenticate'] = 'Negotiate' return response content = return render(request, 'gssapi_test/index.html', content) Сначала нужно проверить передан ли нам заголовок авторизации, если нет — мы должны направить в ответ заголовок с Negotiate, и снова ждать от пользователя Negotiate токен. Этот токен выглядит как большая портянка закодированная в base64. После получения токена, мы инициализируем (авторизуем) сервер нашего приложения в LDAP сервисе, используя функцию authGSSServerInit(). Далее мы авторизуемся в LDAP сервисе от имени пользователя, используя для этого как раз тот токен, который получили из заголовка, функция authGSSServerStep(). Потом мы получаем principal пользователя, который будем использовать в качестве user, при выполнении запроса в БД. А так же, нам необходимо сформировать кэш битела Kerberos, который будет использован автоматически для того, что бы авторизовать нас в PostgreSQL, функция authGSSServerStoreDelegate(). Данная функция есть только в самой последней версии этого пакета, поэтому нужно клонировать себе исходники с git и сделать build.
Браузер должен быть настроен на отдачу Negotiate, по умолчанию эта опция отключена. Все тесты проводились на Firefox в CentOS7, так же на всех серверах был установлен CentOS7.
В добавок, у нас может возникнуть проблема, при которой кэш билета, сформированный нашей функцией, не будет виден нашему процессу и соответственно мы получим, что пользователь не авторизовался в GSSAPI. Она решается настройкой кеширования билетов в krb5.conf. На всякий случай приведу пример нашего конфига:
/etc/krb5.conf
includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = DOMAIN.RU dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 # если раскомментировать опцию - работать не будет #default_ccache_name = KEYRING:persistent:% #Нужно для определения параметра KRB5_KTNAME в облатси видимости приложения default_keytab_name = FILE:/etc/httpd/http.keytab [realms] DOMAIN.RU = < kdc = ldap-server-host.domain.ru:88 master_kdc = ldap-server-host.domain.ru:88 admin_server = ldap-server-host.domain.ru:749 kpasswd_server = ldap-server-host.domain.ru:464 default_domain = domain.ru pkinit_anchors = FILE:/etc/domain/ca.crt >[domain_realm] .domain.ru = DOMAIN.RU domain.ru = DOMAIN.RU .domain.ru = DOMAIN.RU Данный кусок кода создан для того, что бы помочь понять как происходит авторизация и делегация прав, далее с этими знаниями можно строить декораторы авторизации и бэки общения с базой. Пакет ccs-pykerberos был разработан компанией Apple, для своих внутренних нужд, соответственно приведу ссылку на их код, где они его используют. Нам он очень помог в понимании того, что они разработали ccs-calendarserver/twistedcaldav/authkerb.py
Полезные ссылки
- Настройка Kerberos+LDAP
- Реализация похожей задачи на Java
- Настройка nginx на работу по SPNEGO
- Спецификация RFC2744
- Спецификация RFC4559, описывающая SPNEGO
21.6. GSSAPI Аутентификация
GSSAPI — это стандартный отраслевой протокол для безопасной аутентификации, определенный в RFC 2743 . PostgreSQL поддерживает GSSAPI для аутентификации, шифрования связи или того и другого. GSSAPI обеспечивает автоматическую аутентификацию (единый вход) для систем, которые ее поддерживают. Сама аутентификация безопасна. Если используется шифрование GSSAPI или SSL, данные, отправляемые по соединению с базой данных, будут зашифрованы; иначе не будет.
Поддержка GSSAPI должна быть включена при сборке PostgreSQL; см. Chapter 17 для получения дополнительной информации.
Когда GSSAPI использует Kerberos, он использует стандартное имя субъекта-службы (идентификационного удостоверения) в формате servicename/hostname@realm . Основное имя, используемое конкретной установкой, никаким образом не зашифровано на сервере PostgreSQL; скорее, он указан в файле keytab, который сервер считывает, чтобы определить его личность. Если в файле keytab указано несколько участников, сервер примет любой из них. Имя области сервера — это предпочтительная область, указанная в конфигурации Kerberos file(s), доступной для сервера.
При подключении клиент должен знать основное имя сервера, к которому он намеревается подключиться. Часть принципала servicename обычно имеет значение postgres , но другое значение можно выбрать с помощью параметра подключения libpq krbsrvname . Часть hostname — это полное имя хоста, к которому libpq приказано подключиться. Имя области — это предпочтительная область, указанная в конфигурации Kerberos file(s), доступной для клиента.
Клиент также будет иметь имя участника для своего собственного удостоверения (и у него должен быть действительный билет для этого principal).. Чтобы использовать GSSAPI для аутентификации, субъект клиента должен быть связан с именем пользователя базы данных PostgreSQL. Файл конфигурации pg_ident.conf можно использовать для сопоставления участников с именами пользователей; например, pgusername@realm можно сопоставить только с pgusername . В качестве альтернативы вы можете использовать полное имя участника username@realm в качестве имени роли в Q72. 53Q без какого-либо отображения.
PostgreSQL также поддерживает сопоставление принципалов клиента с именами пользователей, просто удаляя область из принципала. Этот метод поддерживается для обратной совместимости и настоятельно не рекомендуется, так как в этом случае невозможно отличить разных пользователей с одним и тем же именем пользователя, но из разных областей. Чтобы включить это, задайте для include_realm значение 0. Для простых установок с одной областью это в сочетании с настройкой параметра krb_realm (который проверяет, соответствует ли основная область точно тому, что указано в параметре krb_realm ) по-прежнему безопасно; но это менее эффективный подход по сравнению с указанием явного отображения в pg_ident.conf .
Расположение файла keytab сервера определяется параметром конфигурации krb_server_keyfile . Из соображений безопасности рекомендуется использовать отдельную таблицу ключей только для сервера PostgreSQL, а не позволять серверу читать системный файл таблицы ключей. Убедитесь, что файл keytab вашего сервера доступен для чтения (и желательно только для чтения, но не для записи) для учетной записи сервера PostgreSQL. (See также Section 19.1 .)
Файл keytab создается с помощью программного обеспечения Kerberos; подробности см. в документации по Kerberos. В следующем примере показано, как это сделать с помощью инструмента kadmin в реализациях MIT-compatible Kerberos 5:
kadmin% addprinc -randkey postgres/server.my.domain.org kadmin% ktadd -k krb5.keytab postgres/server.my.domain.org
Для метода аутентификации GSSAPI поддерживаются следующие параметры аутентификации:
include_realm
Если установлено значение 0, имя области из принципала аутентифицированного пользователя удаляется перед передачей через сопоставление имени пользователя ( Section 21.2 ). Это не рекомендуется и в первую очередь доступно для обратной совместимости, поскольку оно небезопасно в средах с несколькими областями, если также не используется krb_realm . Рекомендуется оставить для include_realm значение по умолчанию (1) и предоставить явное сопоставление в pg_ident.conf для преобразования основных имен в имена пользователей PostgreSQL.
Разрешает сопоставление принципалов клиента с именами пользователей базы данных. Подробности см. в Section 21.2 . Для принципала GSSAPI/Kerberos, такого как [email protected] (или, реже, username/[email protected] ), имя пользователя, используемое для сопоставления, — [email protected] (или username/[email protected] , respectively),, если только include_realm не установлено на 0, и в этом случае username (или username/hostbased ) — это то, что отображается как системное имя пользователя при сопоставлении.
Устанавливает область для сопоставления основных имен пользователей. Если этот параметр установлен, будут приниматься только пользователи этой области. Если он не установлен, пользователи любой области могут подключаться, в зависимости от того, какое сопоставление имен пользователей выполнено.
В дополнение к этим настройкам, которые могут различаться для разных записей pg_hba.conf , существует общесерверный параметр конфигурации krb_caseins_users . Если для этого параметра задано значение true, участники клиента сопоставляются с записями пользовательской карты без учета регистра. krb_realm , если он установлен, также сопоставляется без учета регистра.