Я настроил несколько серверов Linux для аутентификации с Active Directory Kerberos с использованием sssd на RHEL6. Я также включил аутентификацию GSSAPI в надежде на вход без пароля.
Но мне не удаётся заставить Putty (0.63) проходить аутентификацию без пароля.
GSSAPI работает между системами Linux (клиент openSSH), настроенными для аутентификации AD, используя параметры .ssh/config для включения GSSAPI.
Он также работает из Cygwin (клиент openSSH), используя те же настройки .ssh/config, а также запуская команду kinit для получения тикета.
Также Samba распространяется на все системы Linux, включая домашние каталоги, работающие из проводника Windows без запроса пароля (я не уверен, играет ли здесь роль GSSAPI).
Что я могу попробовать сделать, чтобы устранить эту неполадку? Большинство моих пользователей используют Putty. Кроме того, я не являюсь администратором Windows, поэтому не могу ничего делать на контроллерах домена. Моя учетная запись имеет только привилегии на добавление серверов в домен AD.
Я включил протоколирование пакетов SSH в putty. Мне это показалось интересным, но пока не знаю, что делать с этой информацией:
Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
решение1
На компьютерах Windows, входящих в домен Active Directory, пользователи получают свой билет на выдачу билетов Kerberos при входе в Windows, и PuTTY может использовать его для аутентификации, если аутентификация GSSAPI включена в конфигурации PuTTY Connection|SSH|Auth|GSSAPI (и другие методы аутентификации, которые он пробует до GSSAPI, такие как открытый ключ через Pageant, не настроены или отключены в Connection|SSH|Auth).
[Если вам также необходимо делегирование билетов (например, для монтирования файловых систем Kerberos на сервере после входа в систему), убедитесь, что делегирование GSSAPI также включено в PuTTY,исерверы, на которые вы входите, отмечены в Active Directory на вкладке «Делегирование» как «Доверьте этому компьютеру делегирование полномочий любой службе (только Kerberos)", которые по умолчанию не являются таковыми. Последний параметр доверия в AD, как ни странно, необходим только для делегирования работы с клиентами Windows, такими как PuTTY; он не нужен для клиентов Linux "ssh -K".]
На самоуправляемых (персональных) машинах Windows, которые не являются частью домена Active Directory, вы все равно можете использовать аутентификацию Kerberos/GSSAPI (и делегирование билетов) через PuTTY, но вам придется получить билет самостоятельно. К сожалению, Windows 7 не поставляется с установленным эквивалентом программы kinit (чтобы вы могли вручную запросить билет), и PuTTY также не запрашивает ваш пароль Kerberos, если у вас нет билета. Поэтому вам придется установитьMIT Kerberos для Windowsпакет, который включает как обычные инструменты командной строки kinit/klist/kdestroy, так и удобный инструмент GUI "MIT Kerberos Ticket Manager". Используйте их для получения билета, а затем PuTTY автоматически будет использовать библиотеку MIT GSSAPI вместо библиотеки Microsoft SSPI, и все должно работать. Если запущен "MIT Kerberos Ticket Manager", он автоматически запросит у вас пароль Kerberos, когда PuTTY потребуется билет, поэтому хорошей идеей будет связать его с папкой Startup.
Обновлять:Начиная с Windows 10 версии 21H1 и Windows Server 2022,OpenSSH для Windows(версия 8.1 или новее) клиент и сервер, встроенные в Windows, теперь также поддерживают аутентификацию и делегирование GSSAPI (т. е. ssh -K). Так что если вам нужно только это, с 2021 года вам больше не нужно устанавливать PuTTY и MIT Kerberos.
решение2
Сначала дважды проверьте, что ваш klist-вывод на Windows-боксе, на котором запущен PuTTY, показывает действительный TGT. Затем в конфигурации для вашего сеанса PuTTY убедитесь, чтоПопытка аутентификации GSSAPIвключен в Connection - SSH - Auth - GSSAPI. Наконец, убедитесь, что он настроен на автоматический вход с вашим именем пользователя в Connection - Data. Вы можете либо явно указать имя пользователя, либо выбрать переключатель дляИспользовать системное имя пользователя.
Раньше это было все, что мне требовалось для того, чтобы вход по SSH без пароля через Kerberos работал.
решение3
Проблема была в настройке Windows Kerberos. Я думаю, что наш Active Directory настроен странно, я не знаю, я не администратор Windows.
Но я решил проблему, вручную настроив Kerberos с помощью ksetup в интерфейсе командной строки Windows 7.
После перезагрузки моей удаленной рабочей станции я не смог войти в свой ПК. Это потому, что в исходной конфигурации часть TLD моего домена области всегда отсутствовала (domain\user), но после того, как я вручную настроил ее, мне пришлось изменить свой домен входа, чтобы он отражал полное имя домена области (domain.TLD\user), и я смог войти в свой ПК с Windows, хотя теперь, похоже, аутентификация занимает больше времени.
До внесения изменений вывод ksetup отображал только мою область по умолчанию, и она была в нижнем регистре.
Я использовал «nslookup -type=SRV _kerberos._tcp.domain.TLD», чтобы получить все серверы KDC для моей области.
Я не устанавливал никаких флагов.
Я установил сопоставленное имя пользователя "ksetup /mapuser[email protected]пользователь "
Ресурсы, которые я использовал: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC
https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html
Если у кого-то есть предложения, которые я могу дать администраторам Windows о том, как это можно исправить (она сломана?), я передам их.