L envía nombre de usuario y solicitud de autenticación SSH a S1
S1 devuelve los mecanismos de autenticación SSH disponibles, con "contraseña" como uno de ellos
L elige "contraseña" y envía la contraseña simple a S1
S1 da nombre de usuario y contraseña a la pila PAM.
En S1, PAM (generalmente pam_krb5o pam_sss) solicita un TGT (ticket de concesión de tickets) al KDC de Kerberos.
S1 obtiene un TGT.
Estilo antiguo (sin autorización previa): S1 envía un AS-REQ y recibe un AS-REP que contiene el TGT.
Nuevo estilo (con preautorización): S1 usa su contraseña para cifrar la marca de tiempo actual y la adjunta al AS-REQ. El servidor descifra la marca de tiempo y verifica que esté dentro del intervalo de tiempo permitido; Si el descifrado falla, la contraseña se rechaza inmediatamente. De lo contrario, se devuelve un TGT en el AS-REP.
S1 intenta descifrar el TGT utilizando una clave generada a partir de su contraseña. Si el descifrado tiene éxito, la contraseña se acepta como correcta.
El TGT se almacena en un caché de credenciales recién creado. (Puede inspeccionar la $KRB5CCNAMEvariable de entorno para encontrar el ccache, o usar klistpara enumerar su contenido).
S1 usa PAM para realizar verificaciones de autorización (dependientes de la configuración) y abrir la sesión.
Si pam_krb5se llama en la etapa de autorización, verifica si ~/.k5loginexiste. Si lo hace, debe enumerar el principal Kerberos del cliente. De lo contrario, el único principal permitido es .username@DEFAULT-REALM
Segundo inicio de sesión:
S1 envía nombre de usuario y solicitud de autenticación SSH a S2
S2 devuelve auth mechs disponibles, uno de ellos es "gssapi-with-mic" 1
S1 solicita un boleto para , enviando un TGS-REQ con el TGT al KDC, y recibiendo un TGS-REP con el boleto de servicio del mismo.host/s2.example.com@EXAMPLE.COM
S1 genera un "AP-REQ" (solicitud de autenticación) y lo envía a S2.
S2 intenta descifrar la solicitud. Si tiene éxito, se realiza la autenticación. (PAM no se utiliza para la autenticación).
Otros protocolos, como LDAP, pueden optar por cifrar la transmisión de datos adicionales con una "clave de sesión" que se incluyó con la solicitud; Sin embargo, SSH ya ha negociado su propia capa de cifrado.
Si la autenticación se realiza correctamente, S2 usa PAM para realizar verificaciones de autorización y abrir la sesión, igual que S1.
Si se habilitó el reenvío de credenciales y el TGT tiene el indicador "reenviable", entonces S1 solicita una copia del TGT del usuario (con el conjunto de indicadores "reenviado") y lo envía a S2, donde se almacena en un nuevo ccache. Esto permite inicios de sesión recursivos autenticados por Kerberos.
Tenga en cuenta que también puede obtener TGT a nivel local. En Linux, puede hacer esto usando kinit, luego conectarse usando ssh -K. Para Windows, si ha iniciado sesión en un dominio de Windows AD, Windows lo hace por usted; de lo contrario, se puede usar MIT Kerberos . PuTTY 0.61 admite el uso de Windows (SSPI) y MIT (GSSAPI), aunque debe habilitar el reenvío (delegación) manualmente.
1gssapi-keyex también es posible pero no fue aceptado en OpenSSH oficial.
¿Podría dar más detalles sobre la relación entre la contraseña, el TGT y la respuesta del KDC? No está claro cómo PAM decide si la contraseña es correcta.
Phil
NOTA: Esta oración es incorrecta: "S1 envía un TGS-REQ y recibe un TGS-REP que contiene el TGT". Incorrecto porque los TGT vienen como parte de AS_REP. Un Boleto de Servicio regresará con el TGS_REPn
jouell
1
Las versiones recientes de OpenSSH tienen intercambio de claves. Creo que 4.2p1 fue la primera versión en tener los parches. ( sxw.org.uk/computing/patches/openssh.html )
quinnr
No, no lo hacen. Esos son parches de terceros . Eso es lo que quise decir con "no aceptado en OpenSSH oficial"
grawity
0
En pocas palabras: idealmente, los tickets de Kerberos se deben obtener en su terminal (L), ya sea con un kinitcomando o como parte de la secuencia de inicio de sesión local en una configuración llamada "inicio de sesión único". Los sistemas remotos (S1, S2) serían accesibles sin solicitudes de contraseña. Un acceso encadenado (L → S1 → S2) sería posible empleando una técnica conocida como "reenvío de tickets". Dicha configuración requiere, en particular, que se pueda acceder directamente al KDC desde el terminal (L).
La otra respuesta por gravedad explica este enfoque en detalle.
El único paso no obvio aquí sería que hay un módulo PAM en S1 que utilizó sus credenciales para realizar una kinity le da un ticket de concesión de K (autenticación del cliente). Luego, cuando SSH a S2 utiliza la autenticación Kerberos, se lleva a cabo una autenticación de servicio de cliente. No veo el beneficio de pasar por todos los intercambios tediosos mensaje por mensaje.
Lance un -vvvcomando ssh si desea ver cada mensaje y leer la descripción de Wikipedia de Kerberos.
En pocas palabras: idealmente, los tickets de Kerberos se deben obtener en su terminal (L), ya sea con un
kinitcomando o como parte de la secuencia de inicio de sesión local en una configuración llamada "inicio de sesión único". Los sistemas remotos (S1, S2) serían accesibles sin solicitudes de contraseña. Un acceso encadenado (L → S1 → S2) sería posible empleando una técnica conocida como "reenvío de tickets". Dicha configuración requiere, en particular, que se pueda acceder directamente al KDC desde el terminal (L).La otra respuesta por gravedad explica este enfoque en detalle.
fuente
El único paso no obvio aquí sería que hay un módulo PAM en S1 que utilizó sus credenciales para realizar una
kinity le da un ticket de concesión de K (autenticación del cliente). Luego, cuando SSH a S2 utiliza la autenticación Kerberos, se lleva a cabo una autenticación de servicio de cliente. No veo el beneficio de pasar por todos los intercambios tediosos mensaje por mensaje.Lance un
-vvvcomando ssh si desea ver cada mensaje y leer la descripción de Wikipedia de Kerberos.fuente