Autenticación de masilla Kerberos / GSSAPI

9

Configuré algunos servidores Linux para autenticarme con Active Directory Kerberos usando sssd en RHEL6. También habilité la autenticación GSSAPI con la esperanza de inicios de sesión sin contraseña.

Pero parece que no puedo hacer que Putty (0.63) se autentique sin una contraseña.

GSSAPI funciona entre sistemas Linux (cliente openSSH) que están configurados para autenticación AD, utilizando la configuración .ssh / config para habilitar GSSAPI.

También funciona desde Cygwin (cliente openSSH), utilizando la misma configuración .ssh / config, así como ejecutando el comando kinit para obtener un ticket.

También Samba comparte en todos los sistemas Linux, incluidos los directorios de inicio que funcionan desde el Explorador de Windows sin requerir una contraseña (no estoy seguro de si GSSAPI entra en juego allí)

¿Qué tipo de cosas puedo tratar de solucionar esto? La mayoría de mis usuarios usan Putty. Además, no soy un administrador de Windows, así que no puedo hacer nada en los controladores de dominio. Mi cuenta solo tiene privilegios para agregar servidores al dominio AD.


Encendí el registro de paquetes SSH de masilla. Encontré este tipo de interesante, todavía no estoy seguro de qué hacer con esta información:

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.
xdaxdb
fuente
1
Activar la depuración en la noche ssh daemon muestra información útil. Siempre puede iniciar una segunda instancia en un puerto diferente para realizar pruebas.
Paul Haldane

Respuestas:

7

En las máquinas Windows que forman parte de un dominio de Active Directory, los usuarios reciben su boleto de concesión de tickets Kerberos cuando inician sesión en Windows, y PuTTY puede usarlo para la autenticación si la autenticación GSSAPI está habilitada en PuTTY Configuration Connection | SSH | Auth | GSSAPI (y otros métodos de autenticación que intenta antes de GSSAPI, como la clave pública a través del concurso, no están configurados o deshabilitados en Connection | SSH | Auth).

[Si también necesita delegación de tickets (p. Ej., Para montar sistemas de archivos kerberizados en el servidor después de iniciar sesión), asegúrese de que la delegación GSSAPI también esté habilitada en PuTTY, y que los servidores en los que inicia sesión estén marcados en Active Directory en la pestaña Delegación como " Confíe en esta computadora para la delegación a cualquier servicio (solo Kerberos) ", que no son por defecto. Es extraño que esta última configuración de confianza en AD solo sea necesaria para que la delegación funcione desde clientes de Windows como PuTTY; no es necesario para clientes Linux "ssh -K".]

En máquinas Windows (personales) autogestionadas que no son parte de un dominio de Active Directory, aún puede usar la autenticación Kerberos / GSSAPI (y la delegación de tickets) a través de PuTTY, pero debe obtener el ticket usted mismo. Desafortunadamente, Windows 7 no viene instalado con ningún equivalente del programa kinit (para que usted solicite manualmente un ticket), y PuTTY tampoco le solicita su contraseña de Kerberos si no tiene un ticket. Por lo tanto, debe instalar MIT Kerberos para Windowspaquete, que incluye las herramientas habituales de línea de comandos kinit / klist / kdestroy, así como una herramienta GUI ordenada "MIT Kerberos Ticket Manager". Úselos para obtener su boleto, y luego PuTTY usará automáticamente la biblioteca MIT GSSAPI en lugar de la SSPI de Microsoft, y todo debería funcionar. Si el "MIT Kerberos Ticket Manager" se está ejecutando, le pedirá automáticamente su contraseña de Kerberos cuando PuTTY necesite un ticket, por lo que es una buena idea vincularlo desde la carpeta Inicio.

Markus Kuhn
fuente
1
Desde entonces, he aprendido que Windows realmente tiene una especie de equivalente del kinitcomando MIT Kerberos llamado cmdkey.
Markus Kuhn el
1
Con respecto a la habilitación de la delegación de tickets, si usted es uno de los que comprende que Active Directory es realmente solo Microsoft LDAPv3 bajo el capó: asegúrese de que la entrada LDAP del principal de servicio al que desea poder delegar un ticket Kerberos tenga en su userAccountControl el bit TRUSTED_FOR_DELEGATION = 0x80000 = 524288 establecido.
Markus Kuhn el
Para su información a cualquiera que esté considerando configurar "Confíe en esta computadora para la delegación a cualquier servicio (solo Kerberos)", por ejemplo, la delegación Kerberos sin restricciones, esto tiene serias implicaciones de seguridad que debe considerar. Recomiendo leer adsecurity.org/?p=1667 primero.
Brad
3

Primero verifique que su salida de klist en el cuadro de Windows que ejecuta PuTTY muestre un TGT válido. Luego, en la configuración de su sesión PuTTY, asegúrese de que la autenticación Intento GSSAPI esté habilitada Connection - SSH - Auth - GSSAPI. Finalmente, asegúrese de que esté configurado para iniciar sesión con su nombre de usuario automáticamente Connection - Data. Puede especificar explícitamente el nombre de usuario o seleccionar el botón de radio para Usar nombre de usuario del sistema .

Históricamente, eso es todo lo que necesito hacer para que el inicio de sesión SSH sin contraseña funcione a través de Kerberos.

Ryan Bolger
fuente
1
Parece que klist tgt tiene sentido para mí. dice que es reenviable también. klist muestra 5 claves, para cosas como Exchange. También tengo un ticket para el servidor Linux al que estoy tratando de enviar ssh. He revisado la configuración de masilla 100 veces. Todos los documentos / guías en línea dicen lo mismo, así que estoy seguro de que la parte está configurada correctamente.
xdaxdb
3

El problema estaba en la configuración de Windows Kerberos. Creo que nuestro Active Directory está configurado de forma original, realmente no sé si no soy un administrador de Windows.

Pero solucioné el problema configurando manualmente Kerberos usando ksetup en la CLI de Windows 7.

Después de reiniciar mi estación de trabajo remota, no pude iniciar sesión en mi PC. Esto se debe a que en la configuración original, la parte de TLD de mi dominio de dominio siempre estuvo ausente (dominio \ usuario), pero después de configurarla manualmente tuve que cambiar mi dominio de inicio de sesión para reflejar el nombre de dominio de dominio completo (dominio.TLD \ usuario) y Pude iniciar sesión en mi PC con Windows, aunque ahora parece que me lleva más tiempo autenticarme.

Antes de los cambios, la salida de ksetup solo mostraba mi reino predeterminado, y estaba en minúsculas.

Usé "nslookup -type = SRV _kerberos._tcp.domain.TLD" para obtener todos los servidores kdc de mi reino.

No puse ninguna bandera.

Configuré mapeado mi nombre de usuario "ksetup / mapuser [email protected] user"

Recursos que utilicé: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

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

Si alguien tiene alguna sugerencia que pueda darle a la gente de administración de Windows sobre cómo pueden solucionar esto (¿está roto?), Lo pasaré.

xdaxdb
fuente