Putty Kerberos/GSSAPI аутентификация
Я настроил несколько серверов 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.
3 ответа
На компьютерах с Windows, которые являются частью домена Active Directory, пользователи получают свой билет на выдачу билетов Kerberos при входе в Windows, и PuTTY может использовать его для аутентификации, если аутентификация GSSAPI включена в соединении конфигурации PuTTY |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 понадобится билет, поэтому рекомендуется связать его из папки "Автозагрузка".
Сначала дважды проверьте, что ваш вывод klist в окне Windows с PuTTY показывает допустимый TGT. Затем в конфигурации для вашего сеанса PuTTY убедитесь, что включена попытка аутентификации GSSAPI в Connection - SSH - Auth - GSSAPI, Наконец, убедитесь, что он настроен на автоматический вход в систему с вашим именем пользователя в Connection - Data, Вы можете явно указать имя пользователя или выбрать переключатель Использовать системное имя пользователя.
Исторически это все, что мне нужно было сделать, чтобы беспарольный вход в SSH работал через Kerberos.
Проблема была в настройке Windows Kerberos. Я думаю, что наш Active Directory настроен в стиле фанк, я действительно не знаю, что я не администратор Windows.
Но я исправил проблему, вручную настроив Kerberos с помощью ksetup в CLI Windows 7.
После перезагрузки на удаленную рабочую станцию я не смог войти на свой ПК. Это связано с тем, что в исходной конфигурации часть TLD моего домена realm всегда отсутствовала (домен \ пользователь), но после того, как я настроил ее вручную, мне пришлось изменить свой домен для входа, чтобы он отражал полное имя домена realm (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, как они могут это исправить (это сломано?), Я передам это.