¿Cómo funciona Kerberos con SSH?

Primer inicio de sesión:

• L envía el nombre de usuario y la 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 proporciona nombre de usuario y contraseña a la pila PAM.
• En S1, PAM (generalmente pam_krb5 o pam_sss ) solicita un TGT (boleto de concesión de boletos) del Kerberos KDC.
  1. 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 autorización previa):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 sesgo de tiempo permitido; si falla el descifrado, la contraseña se rechaza inmediatamente. De lo contrario, se devuelve un TGT en AS-REP.
  2. 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.
  3. El TGT se almacena en una memoria caché de credenciales recién creada. (Puede inspeccionar el $KRB5CCNAME variable de entorno para encontrar el ccache, o use klist para enumerar su contenido.)
• S1 usa PAM para realizar verificaciones de autorización (dependiendo de la configuración) y abrir la sesión.
  • Si pam_krb5 se llama en etapa de autorización, verifica si ~/.k5login existe Si es así, debe enumerar el principal de Kerberos del cliente. De lo contrario, el único principal permitido es username@DEFAULT-REALM .

Segundo inicio de sesión:

• S1 envía el nombre de usuario y la solicitud de autenticación SSH a S2
• S2 devuelve los mecanismos de autenticación disponibles, uno de ellos es "gssapi-with-mic"
• S1 solicita un boleto para host/s2.example.com@EXAMPLE.COM , enviando un TGS-REQ con el TGT al KDC, y recibiendo de este un TGS-REP con el ticket de servicio.
• 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 más transmisiones de datos con una "clave de sesión" que se incluyó con la solicitud; sin embargo, SSH ya negoció su propia capa de cifrado.
• Si la autenticación tiene éxito, S2 usa PAM para realizar comprobaciones 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", S1 solicita una copia del TGT del usuario (con el indicador "reenviado") y lo envía a S2, donde se almacena en un nuevo caché . Esto permite inicios de sesión recursivos autenticados por Kerberos.

Tenga en cuenta que también puede obtener TGT localmente. En Linux, puede hacer esto usando kinit , luego conéctate usando ssh -K . Para Windows, si ha iniciado sesión en un dominio AD de Windows, Windows lo hace por usted; de lo contrario, se puede utilizar MIT Kerberos. PuTTY 0.61 admite el uso de Windows (SSPI) y MIT (GSSAPI), aunque debe habilitar el reenvío (delegación) manualmente.

gssapi-keyex también es posible pero no fue aceptado en OpenSSH oficial.