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 iniciar sesión sin contraseña.
Pero parece que no puedo lograr 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), usando la misma configuración .ssh/config y ejecutando el comando kinit para obtener un ticket.
Además, Samba comparte en todos los sistemas Linux, incluidos los directorios de inicio, que funcionan desde el Explorador de Windows sin necesidad de contraseña (no estoy seguro de si GSSAPI entra en juego allí)
¿Qué tipo de cosas puedo intentar para solucionar este problema? La mayoría de mis usuarios usan Putty. Además, no soy administrador de Windows, por lo que no puedo hacer nada con los controladores de dominio. Mi cuenta solo tiene privilegios para agregar servidores al dominio AD.
Activé el registro de paquetes SSH de PuTTY. Encontré esto algo 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.
Respuesta1
En las máquinas Windows que forman parte de un dominio de Active Directory, los usuarios reciben su ticket de concesión de vales de Kerberos cuando inician sesión en Windows, y PuTTY puede usarlo para la autenticación si la autenticación GSSAPI está habilitada en Configuración de PuTTY Conexión|SSH|Auth|GSSAPI (y otros métodos de autenticación que intenta antes de GSSAPI, como la clave pública a través de Pageant, no están configurados o deshabilitados en Conexión|SSH|Auth).
[Si también necesita delegación de tickets (por ejemplo, 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.ylos 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 delegar a cualquier servicio (solo Kerberos)", que no son los predeterminados. Curiosamente, esta última configuración de confianza en AD solo es necesaria para que la delegación funcione desde clientes de Windows como PuTTY; no es necesaria para clientes "ssh -K" de Linux.]
En máquinas Windows autoadministradas (personales) que no forman 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 pueda solicitar un ticket manualmente), y PuTTY tampoco le solicita su contraseña de Kerberos si no tiene un ticket. Por lo tanto, hay que instalar elMIT Kerberos para Windowspaquete, que incluye las habituales herramientas de línea de comandos kinit/klist/kdestroy, así como una elegante herramienta GUI "MIT Kerberos Ticket Manager". Úselos para obtener su boleto, y luego PuTTY usará automáticamente la biblioteca MIT GSSAPI en lugar de la de Microsoft SSPI, y todo debería funcionar. Si se está ejecutando el "MIT Kerberos Ticket Manager", le solicitará automáticamente su contraseña de Kerberos cuando PuTTY necesite un ticket, por lo que es una buena idea vincularlo desde la carpeta Inicio.
Actualizar:A partir de Windows 10 versión 21H1 y Windows Server 2022, elOpenSSH para Windows(versión 8.1 o posterior) el cliente y servidor integrados en Windows ahora también admiten la autenticación y delegación GSSAPI (es decir, ssh -K). Entonces, si todo lo que necesitas es eso, a partir de 2021 ya no necesitarás instalar PuTTY y MIT Kerberos.
Respuesta2
Primero verifique que la salida de su 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 deIntentar autenticación GSSAPIestá habilitado en Connection - SSH - Auth - GSSAPI. Finalmente, asegúrese de que esté configurado para iniciar sesión con su nombre de usuario automáticamente en Connection - Data. Puede especificar explícitamente el nombre de usuario o seleccionar el botón de opción paraUsar nombre de usuario del sistema.
Históricamente, eso es todo lo que he tenido que hacer para que el inicio de sesión SSH sin contraseña funcione a través de Kerberos.
Respuesta3
El problema estaba en la configuración de Windows Kerberos. Creo que nuestro Active Directory está configurado de manera original, realmente no sé, no soy administrador de Windows.
Pero solucioné el problema configurando Kerberos manualmente 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 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 completo (dominio.TLD\usuario) y Pude iniciar sesión en mi PC con Windows, aunque ahora parece que la autenticación lleva más tiempo.
Antes de los cambios, la salida de ksetup solo mostraba mi dominio predeterminado y estaba en minúsculas.
Utilicé "nslookup -type=SRV _kerberos._tcp.domain.TLD" para obtener todos los servidores kdc para mi reino.
No puse ninguna bandera.
Configuré asignado mi nombre de usuario " ksetup /mapuser[correo electrónico protegido]usuario "
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 los administradores de Windows sobre cómo pueden solucionar este problema (¿está roto?), se la transmitiré.