Я настроил несколько серверов 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 Explorer без необходимости ввода пароля (я не уверен, что GSSAPI вступит в игру)
Что я могу попробовать, чтобы решить эту проблему? Большинство моих пользователей используют Putty. Кроме того, я не администратор Windows, поэтому ничего не могу сделать с контроллерами домена. Моя учетная запись имеет права только на добавление серверов в домен AD.
Я включил ведение журнала пакетов SSH. Мне это показалось интересным, я пока не знаю, что делать с этой информацией:
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.
На компьютерах Windows, которые являются частью домена Active Directory, пользователи получают свой билет для выдачи билетов Kerberos при входе в Windows, и PuTTY может использовать его для аутентификации, если аутентификация GSSAPI включена в PuTTY Configuration Connection | SSH | Auth | GSSAPI (и другие методы аутентификации, которые он пробует до GSSAPI, такие как открытый ключ через Pageant, не настраиваются и не отключаются в Connection | SSH | Auth).
[Если вам также требуется делегирование билетов (например, для монтирования керберизованных файловых систем на сервере после входа в систему), убедитесь, что делегирование 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, так и удобный инструмент с графическим интерфейсом «MIT Kerberos Ticket Manager». Используйте их, чтобы получить свой билет, и тогда PuTTY автоматически будет использовать библиотеку MIT GSSAPI вместо библиотеки Microsoft SSPI, и все должно работать. Если запущен «MIT Kerberos Ticket Manager», он автоматически запросит у вас пароль Kerberos, когда PuTTY понадобится билет, поэтому рекомендуется связать его из папки Startup.
Проблема была в настройке Windows Kerberos. Я думаю, что наша Active Directory настроена напуганно, я действительно не знаю, что я не администратор Windows.
Но я решил проблему, настроив Kerberos вручную с помощью ksetup в Windows 7 CLI.
После перезагрузки удаленной рабочей станции я не смог войти в свой компьютер. Это связано с тем, что в исходной конфигурации часть TLD моего домена области всегда отсутствовала (домен \ пользователь), но после того, как я вручную настроил ее, мне пришлось изменить свой домен входа, чтобы отразить полное имя домена области (domain.TLD \ user) и Мне удалось войти в свой компьютер с Windows, хотя, похоже, теперь для аутентификации требуется больше времени.
До изменений в выводе ksetup отображалась только моя область по умолчанию, и она была в нижнем регистре.
Я использовал "nslookup -type = SRV _kerberos._tcp.domain.TLD", чтобы получить все серверы kdc для моей области.
Я не ставил никаких флажков.
Я установил сопоставленное имя пользователя "ksetup / mapuser user@domain.TLD user"
Ресурсы, которые я использовал: 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, как они могут это исправить (это сломано?), Я передам их.
Сначала дважды проверьте, что ваш вывод klist в окне Windows, на котором запущен PuTTY, показывает действительный TGT. Затем в конфигурации вашего сеанса PuTTY убедитесь, что Попытка аутентификации GSSAPI включен в Connection - SSH - Auth - GSSAPI. Наконец, убедитесь, что он настроен для автоматического входа с вашим именем пользователя в Connection - Data. Вы можете явно указать имя пользователя или установить переключатель для Использовать системное имя пользователя.
Исторически сложилось так, что это все, что мне нужно было сделать, чтобы беспарольный вход по SSH работал через Kerberos.