Kerberizar el servicio ssh

Introducción

Kerberos es un protocolo de autenticación que se utiliza en redes para permitir una autenticación reciproca entre cliente y servidor, su función principal es centralizar la autenticación entre usuarios y equipos de una red.

Kerkeberos nos proporciona lo que se denomina autenticación única (Single Sign-On) habilitando al usuario (de esa maquina) la posibilidad de acceder a varios servicios y equipos con una sola instancia de autenticación.

La versión que se va a tratar e implementar en esta entrada es Mit Kerberos 5.

 

Terminología 

  • Realm: define el dominio del que se hará cargo el servidor Kerberos. Se suele usar el dominio DNS de la organización, se escribe en mayúsculas. En esta entrada será CHARLIE.GONZALONAZARENO.ORG
  • Principal: define una entrada en la base de datos que incluye o bien un usuario,equipo o servicio. Por ejemplo se va a definir el principal un usuario de la siguiente forma: usuario@CHARLIE.GONZALONAZARENO.ORG.
  • Ticket: son datos cifrados que kerberos le facilita a los clientes para su autenticación y que esto quede registrado durante una sesión. Hay diferentes tipos de tickets:
    • TGT: para autenticar a un usuario en la red, solicitándose a dicho usuario al iniciar la sesión.
    • TGS: se solicita a un usuario para autenticarse frente a un servidor de la red.
  • KDC: el servidor de kerberos encargado de la autenticación, repartir los TGT y TGS.
  • kadmin-server: servidor maestro de kerberos para administrar los principales.

 

ESQUEMA DE REFERENCIA

 

Requisitos previos (Ambas máquinas)

Para el correcto funcionamiento es necesario que cada una de las máquinas sean capaces de resolver su propio FQDN, acto seguido lo ideal es disponer de un servidor DNS que sea capaz de resolver los nombres de las máquinas en la misma red:

Otro detalle muy importante, es que estén sincronizados los relojes de las máquinas también, para ello:

Configurar bien la zona horaria nuestra, en mi caso:

Elegir: ‘Europe/Madrid’

Instalar el siguiente paquete:

Comando para comprobar:

Añadir en el fichero de configuración /etc/ntp.conf, el servidor de hora y comentar los pool:

Reiniciar el servicio:

Y verificamos que haya adaptado la nueva configuración:

 

Instalación y configuración de kerberos en el servidor (Mickey)

Instalar los siguientes paquetes:

En las ventanas de instalación, añadir la siguiente información:

  • Default Kerberos version 5 realm: CHARLIE.GONZALONAZARENO.ORG
  • Kerberos Servers: mickey.charlie.gonzalonazareno.org
  • Administrative server: mickey.charlie.gonzalonazareno.org

 

Finalizando la instalación:

 

Por lo tanto, vamos a comprobar los ficheros de configuración y realizar unas modificaciones para iniciar ambos servicios:

/etc/krb5kdc/kdc.conf

Quitar el puerto 750 y dejar solamente el puerto 88:

/etc/default/krb5-kdc

Desactivar el modo kerberos 4:

 

/etc/krb5.conf

Comprobamos que ha tomado correctamente los valores de las ventanas de instalación del paquete y añadimos en la sección [domain_realm] nuestro reino en el siguiente formato:

Nota: esta configuración corresponde con el cliente kerberos de la máquina servidor (Mickey).

Arrancando servicios

Para definir nuestro realm ejecutamos la siguiente instrucción:

Esto nos solicitará la clave maestra de kerberos (elegimos una contraseña) y posteriormente a ello, podremos iniciar ambos servicios: Password: myrealm

Comprobamos que efectivamente estén ejecutándose:

Nota: Si no puedes ejecutar el comando netstat, necesitas instalar el paquete net-tools.

Nota: kdc escucha en el puerto 88/udp, y kadmind escucha en el puerto 749/tcp para la utilización del kadmin y 464/udp para kpasswd.

Ahora nos conectaríamos de manera local a kerberos con el usuario administrador que viene de forma predeterminada, y añadiríamos un principal para el usuario con el que nos estamos autenticando, en este caso usuario/admin.

Password: usuario

Si quisieramos que este usuario pudiera dar todos los privilegios de administración, tendriamos que descomentar la linea:

/etc/krb5kdc/kadm5.acl

 

Todos los usuarios, equipos y servicios que queramos que se validen deberán tener su principal en la base de datos de Kerberos. Los usuarios se autenticarán utilizando una contraseña y los equipos o servicios se crearán automáticamente una contraseña aleatoria que se almacenara en un fichero keytab.

Por lo tanto necesitamos crear los principales para los dos equipos (mickey y minnie):

Si volvemos a listar los principales deberían aparecer el principal de usuario y las dos máquinas:

Ficheros Keytab 

Como se ha comentado antes, toda esta información se almacena en lo que se dominan ficheros keytabs, donde se almacena un listado de los principales junto a sus claves, para que puedan autenticarse en la red de forma no interactiva.

Por lo tanto si cualquiera tuviera acceso a un keytab, podria autenticarse con cada uno de los principales que estuvieran definidos en ese mismo keytab.

Ahora en la misma máquina servidor kerberos (mickey), vamos a almacenar los principales de la máquina en /etc/krb5.keytab.

Por otro lado vamos a guardar el principal de la máquina minnie en otro keytab, para exportarlo a dicha máquina.Vamos a utilizar el directorio temporal /tmp para dicha operación:

Podemos consultar los principales existente en un fichero keytab de la siguiente forma:

Si ahora listamos los principales, debemos de ver los creados anteriormente más los que vienen por defecto con kerberos:

Definimos unos nuevos permisos más restrictivos al fichero keytab para que no tenga acceso cualquiera y el propietario será el usuario sshd:

Creamos un principal para el usuario “usuario” que será el que usemos para autenticarnos de forma transparente en el servicio ssh:

Password: USUARIO

Y por último transferimos el keytab donde se encuentra el principal de la máquina minnie, a dicha máquina por scp por ejemplo:

 

Configuración del cliente (Minnie)

Instalar los paquetes:

Introducir la misma información que en la máquina servidor, en la instalación de los paquetes:

  • Default Kerberos version 5 realm: CHARLIE.GONZALONAZARENO.ORG
  • Kerberos Servers: mickey.charlie.gonzalonazareno.org
  • Administrative server: mickey.charlie.gonzalonazareno.org

Añadir en:

/etc/krb5.conf

 

Con la instrucción klist -5 (Para hacer uso exclusivo del modo kerberos 5), podemos ver los tickets de la sesión del usuario actual. Si lo ejecutamos antes de autenticarnos manualmente contra el servidor kerberos tendremos una salida parecida a esta:

Mover de ruta el fichero keytab que hemos transferido a minnie, y asignarle el nuevo propietario y sus correspondientes permisos:

Configuración del servicio SSH en (ambas máquinas)

Deberemos activar varias opciones en los siguientes ficheros:

/etc/ssh/sshd_config

/etc/ssh/ssh_config

Reiniciar el servicio ssh, una vez aplicado los cambios anteriores:

Prueba de funcionamiento

Ahora vamos a probar a como el usuario “usuario” tras autenticarse contra kerberos, podrá de manera transparente autenticarse por ssh desde una máquina a otra.

Para autenticarse en el servidor kerberos, no es necesario tener el usuario creado en el sistema, basta con que exista el principal en la base de datos de kerberos.

Pero para poder hacer la conexión ssh a ambos equipos, si debe de existir en el sistema:

Ahora autenticamos con el usuario desde minnie con el servidor kerberos y comprobamos como ahora tenemos un ticket para la sesión del usuario:

Conexión SSH desde Minnie a Mickey

Si después de autenticarnos contra kerberos con el usuario, hacemos un ssh a la máquina mickey, no debería pedirnos contraseña y si hacemos un klist veremos como tenemos otro ticket:

Si echamos un vistazo al log de mickey, podemos ver el inicio de sesión satisfactorio:

Conexión SSH desde Mickey a Minnie

El pase de diapositivas requiere JavaScript.

Troubleshooting

kinit: Preauthentication failed while getting initial credentials

Si desde el cliente al hacer kinit usuario nos saltará este mensaje, estar seguros de que la contraseña es la de dicho usuario, puede resultar confuso ya que el mensaje no es muy orientativo. No me di cuenta que era eso hasta que probé a autenticarme con el usuario en la propia máquina servidor, donde el mensaje que me devolvió si fue: kinit: Password incorrect while getting initial credentials

Solución: contraseña incorrecta

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Puede deberse a varios motivos, entre ellos:

  • Que el usuario no se encuentre en el sistema remoto.
  • En el fichero /etc/hosts, no estemos resolviendo bien el nombre del host, me paso que se me colo la siguiente linea:

127.0.0.1 localhost

Y me volví loco, hasta que me fije bien a la hora de listar los principales me vi que los principales de los usuarios que se crean automáticamente con kerberos, no tenían como realm mi dominio, sino localhost.

  • Los permisos y propietario de los ficheros keytab.
  • El nombre de la máquina donde instalamos el servidor de kerberos y el servidor administrativo se deben indicar en minusculas.
  • Crear un usuario administrador de kerberos y habilitar la ACL.

 

Cualquier duda o sugerencia siempre es bienvenida 🙂

 

Autor entrada: CharlieJ

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *