Uwierzytelnianie Putty Kerberos / GSSAPI

Skonfigurowałem kilka serwerów Linux do uwierzytelniania przy użyciu Active Directory Kerberos przy użyciu sssd na RHEL6. Włączyłem także uwierzytelnianie GSSAPI w nadziei na logowanie bez hasła.

Ale nie mogę uzyskać uwierzytelnienia Putty (0.63) bez hasła.

GSSAPI działa między systemami Linux (klient openSSH) skonfigurowanymi do uwierzytelniania AD, używając ustawień .ssh / config do włączenia GSSAPI.

Działa również z Cygwin (klient openSSH), używając tych samych ustawień .ssh / config, a także uruchamiając komendę kinit, aby uzyskać bilet.

Również udziały Samby we wszystkich systemach Linux, w tym katalogi domowe działają z Eksploratora Windows bez konieczności podawania hasła (nie jestem pewien, czy GSSAPI jest tam dostępne)

Jakie rzeczy mogę spróbować rozwiązać? Większość moich użytkowników korzysta z Putty. Ponadto nie jestem administratorem systemu Windows, więc nie mogę nic zrobić na kontrolerach domeny. Moje konto ma tylko uprawnienia do dodawania serwerów do domeny AD.

Włączyłem rejestrowanie pakietów Kit SSH. Znalazłem tego rodzaju interesujące, nie jestem jeszcze pewien, co zrobić z tymi informacjami:

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.

Na komputerach z systemem Windows, które są częścią domeny Active Directory, użytkownicy otrzymują bilet do przyznawania biletów Kerberos, gdy logują się do systemu Windows, a PuTTY może używać go do uwierzytelniania, jeśli uwierzytelnianie GSSAPI jest włączone w PuTTY Konfiguracja połączenia | SSH | Auth | GSSAPI (i inne metody uwierzytelniania, które próbuje przed GSSAPI, takie jak klucz publiczny przez Pageant, nie są skonfigurowane ani wyłączone w Connection | SSH | Auth).

[Jeśli potrzebujesz również delegacji biletów (np. Aby zamontować zerkerizowane systemy plików na serwerze po zalogowaniu), upewnij się, że delegacja GSSAPI jest również włączona w PuTTY, a serwery, do których logujesz się, są oznaczone w Active Directory na karcie Delegacja jako „ Ufaj temu komputerowi w kwestii delegowania do dowolnej usługi (tylko Kerberos) ”, którymi nie są domyślnie. To ostatnie ustawienie zaufania w AD jest dziwnie potrzebne tylko do delegowania do pracy z klientami Windows, takimi jak PuTTY; nie jest to konieczne w przypadku klientów Linux „ssh -K”.]

Na samodzielnie zarządzanych (osobistych) komputerach z systemem Windows, które nie są częścią domeny Active Directory, nadal możesz korzystać z uwierzytelniania Kerberos / GSSAPI (i delegowania biletów) za pośrednictwem PuTTY, ale musisz sam zdobyć bilet. Niestety, Windows 7 nie jest instalowany z żadnym odpowiednikiem programu kinit (do ręcznego żądania biletu), a PuTTY również nie monituje o podanie hasła Kerberos, jeśli brakuje biletu. Dlatego musisz zainstalować MIT Kerberos dla Windowspakiet, który zawiera zarówno zwykłe narzędzia wiersza polecenia kinit / klist / kdestroy, jak i zgrabne narzędzie GUI „MIT Kerberos Ticket Manager”. Użyj tych, aby otrzymać bilet, a następnie PuTTY automatycznie użyje biblioteki MIT GSSAPI zamiast Microsoft SSPI i wszystko powinno działać. Jeśli uruchomiony jest „MIT Kerberos Ticket Manager”, automatycznie poprosi o podanie hasła Kerberos, gdy PuTTY potrzebuje biletu, więc dobrym pomysłem jest połączenie go z folderu Autostart.

Najpierw sprawdź dwukrotnie, czy dane wyjściowe klist w polu Windows z uruchomionym PuTTY pokazują prawidłowy TGT. Następnie w konfiguracji sesji PuTTY upewnij się, że włączona jest próba uwierzytelnienia GSSAPIConnection - SSH - Auth - GSSAPI . Na koniec upewnij się, że jest skonfigurowany do automatycznego logowania przy użyciu Twojej nazwy użytkownika Connection - Data. Możesz albo wyraźnie określić nazwę użytkownika, albo wybrać przycisk opcji Użyj nazwy użytkownika systemu .

Historycznie to wszystko, co musiałem zrobić, aby logowanie SSH bez hasła działało przez Kerberos.

Problem dotyczył konfiguracji Kerberos systemu Windows. Wydaje mi się, że nasza usługa Active Directory jest skonfigurowana funky, tak naprawdę nie wiem, czy nie jestem administratorem systemu Windows.

Ale naprawiłem problem, ręcznie konfigurując Kerberos za pomocą ksetup w interfejsie CLI systemu Windows 7.

Po ponownym uruchomieniu na zdalnej stacji roboczej nie mogłem zalogować się na komputerze. Jest tak, ponieważ w oryginalnej konfiguracji część TLD mojej domeny domeny była zawsze nieobecna (domena \ użytkownik), ale po jej ręcznej konfiguracji musiałem zmienić domenę logowania, aby odzwierciedlała pełną nazwę domeny domeny (domena.TLD \ użytkownik) i Byłem w stanie zalogować się na moim komputerze z systemem Windows, chociaż uwierzytelnianie trwa teraz dłużej.

Przed zmianami wyjście ksetup pokazywało tylko moją domyślną sferę i było małe litery.

Użyłem „nslookup -type = SRV _kerberos._tcp.domain.TLD”, aby uzyskać wszystkie serwery KDC dla mojego królestwa.

Nie ustawiłem żadnych flag.

Ustawiłem zamapowaną nazwę użytkownika „ksetup / mapuser użytkownik@domena.TLD użytkownik”

Wykorzystane zasoby: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Jeśli ktoś ma jakieś sugestie, które mogę przekazać administratorom systemu Windows, jak to naprawić (czy jest zepsuty?) Przekażę to dalej.