ASIR2 DOC 2025/26

Assignmets docs for asir2

View on GitHub

Kerberos

Kerberos es un protocolo de autenticación de red que permite a usuarios y servicios verificar sus identidades de forma segura en redes inseguras, usando un tercero de confianza (el KDC) y criptografía de clave secreta para emitir "tickets" digitales, evitando enviar contraseñas por la red. Permite el inicio de sesión único (SSO), autenticando al usuario una sola vez para múltiples servicios.

Arquitectura

Componentes

Componentes Kerberos

Protocolo

Analogía feria atracciones

Kerberos protocol 2

Una forma de pensar en el uso de Kerberos es imaginar que vas a un parque de atracciones. Cuando llegas al parque, te diriges a la puerta principal. Luego, te diriges a la taquilla principal (el servidor de autenticación en el centro de distribución de claves) y compras un pase de un día para el parque (un ticket que te da acceso).

Recibes una pulsera morada (porque el morado es el color del miércoles) que indica que has pagado la entrada para ese día y que tienes acceso completo al parque. La pulsera de color es válida para todo el día.

Mientras estás en el parque, debes adquirir entradas adicionales para las atracciones. Te acercas a la taquilla de la atracción (servidor de tickets) y la empleada se da cuenta de que llevas una pulsera morada. Le dices que quieres montarte en la montaña rusa. Ella te expide un ticket (ticket de sesión) para la montaña rusa.

Cuando llegas a la montaña rusa, el encargado de la montaña rusa ve tu pulsera morada y acepta el ticket que te ha dado la taquillera. El encargado de la montaña rusa no necesita consultar con la taquillera porque ese es el único lugar donde podrías haber conseguido ese ticket.

Al final del día, cuando cierra el parque, la pulsera morada del miércoles ya no te identifica. El color de la pulsera del jueves es naranja. También te diste cuenta de que tú hiciste todo el trabajo. Ninguno de los vendedores de entradas ni los operadores de las atracciones se comunicaron entre sí. Dependía de ti.

Kerberos protocol 1

Kerberos protocol 2

Kerberos protocol 3

Actividad I. Autenticación en un servidr ssh mediante kerberos

Guión esquemático

  1. Crea la red krb-net
  2. Crea las instancias necesarias
  3. Crea,configura y comprueba el correcto funcionamiento del servidor dns para la red krb-net.
  4. Configurar el KDC añadiendo los prear, modificar y activar tu web site basándote en el fichero existente /etc/apache/sites-available/default-ssl.conf
  5. ....

Crea una red denominada krb-net para experimentar y aprender el funcionamiento del protocolo kerberos. La red formada por el KDC, un cliente y un servidor ssh kerberizado, permitirá una vez autenticado el cliente y obtenido el TGT, solicitar el TS al servidor ssh y acceder a el sin necesidad de presentar las credenciales (usuario/contraseña)

Realm Primary KDC User principal Admin principal
ASIR2.GRAO kdc.asir2.grao ubuntu ubuntu/admin

Escenario en Incus

Para llevar a cabo la práctica, deberemos construir el siguiente escenario con contenedores

Las máquinas KDC, krb-cli y ssh-server están en la red krb-net. La resolución de nombres, esencial para que el protocolo de autenticación Keberos, funcione correctamente la hace dnssrv

Network

$ incus network create krb-net \
      ipv4.address=10.144.144.1/24 \
      ipv6.address=none ipv4.nat=true \
      ipv4.dhcp.ranges=10.144.144.100-10.144.144.200 \
      dns.nameservers=10.144.144.2 \
      dns.search=asir2.grao

DNS

En el apartado anterior hemos creado la red asir2.grao(10.144.144.0/24). Para el correcto funcionamiento de kerberos es necesario disponer de un servidor DNS para dicha zona correctamente configurado. Este, tal y como le hemos indicando tiene una ip fija 10.144.144.2 que es la que que el servidor DHCP (10.144.144.1) pasará a sus clientes entre otros parámetros de red. Será necesarios configurar el fichero /etc/netplan/10-lxc.yaml

$ incus launch images:ubuntu/noble dnssrv --network krb-net

Asigna una ip fija al servidor DNS, puedes hacerlo modificando el fichero /etc/netplan/10-lxc.yaml

#/etc/netplan/10-lxc.yaml
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      dhcp-identifier: mac
      addresses: [10.144.144.2/24]
      nameservers:
        addresses: [10.144.144.2]
        search: [asir2.grao]
      routes:
        - to : default
          via: 10.144.144.1

Aplica los cambios mediante el comando netplan apply

Tambíen puedes asignar una ip fija en incus con el siguiente comando

$incus config device set dnssrv eth0 ipv4.address=10.144.144.2

Es necesario instalar en nuestro servidor de nombres de la zona asir2.grao el paquete bind9 enre otras utilidades para que este actue como tal. Nuestra configuración actual que podemos obtenerla mediante el comando resolvectl status indica que el servidor de nombres para resolver nombres de domino es el mismo, por lo que es el pez que se muerde la cola.

Tip

Podemos asignar de forma temporal un servidor de nombres para poder instalar los paquetes mediante el comando resolvectl dns eth0 10.144.144.1

Intala los paquetes necesarios.

$ incus exec dnssrv -- bash -c 'apt-get update && apt-get -y install  aptitude wget bind9 dnsutils bash-completion nano xsel vim'

Responde:

  1. ¿Qué serie de pruebas has llevado a cabo para concluir que es la configuración del servidor de nombres la que no es correcta para poder instalar los paquetes, indica los comandos?
  2. ¿Quién es 10.144.144.1?,¿Por que lo has asignado como servidor de nombres?,¿Qué otras funciones tiene?
  3. ¿Habría funcionado si huberamos puesto los servidores de google 8.8.8.8 como servidores de nombre en nuestra configuración?. ¿Explica el motivo?

Vamos ahora a configurar nuestro servidor de nombres para que sea responsable de la zona asir2.grao, esto quiere decir que es él quien tiene la responsabilidad de devolver la ip correspondiente a las peticiones dentro del dominio asir2.grao. Nuestro servidor de nombres actua como caching nameserver. Las peticiones que este no sepa resolver deberá reenviarlas a otro servidor de nombres.

Note

Las siguientes indicaciones están basada sen el tutorial de configuración del servicio DNS de ubuntu. Se recomienda consultarlas para cualquier duda o aclaración.

A continuación configuramos nuestro servidor como servidor primario de la zona a administrar asir2.grao

#/etc/bind/named.conf.local
zone "asir2.grao" {
    type master;
    file "/etc/bind/db.asir2.grao";
};

Creamos los registros para la zona

#/etc/bind/db.asir2.grao
;
; BIND data file for asir2.grao
;
$TTL    604800
@       IN      SOA     ns.asir2.grao. admin.asir2.grao. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

@       IN      NS      ns.asir2.grao.
@       IN      A       10.144.144.2
ns      IN      A       10.144.144.2
#---------------
#Place your records here
#--------------

Responde:

  1. _¿Qué es un caching nameserver indica las características frente a un DNS forwarder
  2. ¿Por que has indicando 10.144.144.1 como forwarders?. ¿Qué otros valores sería correcto poner?
  3. ¿Investiga cual es el servidor de nombres del IES?, ¿Qué comando has utilizado para saberlo?
  4. Explica con tus propias palabras el siguiente registro

@ IN NS ns.example.com.

Para la resolución inversa (ip -> name)

#/etc/bind/named.conf.local
zone "144.144.10-in-addr.arpa" {
    type master;
    file "/etc/bind/db.144.144.10";
};

#/etc/bind/db.10.144.144
;
; BIND data file for 10.144.144
;
$TTL    604800
@       IN      SOA     ns.asir2.grao. admin.asir2.grao. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL

@       IN      NS      ns.
2       IN      PTR 	ns.asir2.grao
#---------------
#Place your records here
#--------------

Warning

Para el correcto funcionamiento de Kerberos es necesario tener un servidor DNS correctamente configurado y con los registros necesarios.

Testeando el servidor DNS

Es fundamental aprender a testear y comprobar las cosas y no dejar nada al libre albedrio, que será en un alto porcentaje susceptible de fallos y problemas.

Una herramienta muy util para realiza consultas a un servidor de nobres es dig o nslookup

dig @10.144.144.2 kdc.asir2.grao A
dig @10.144.144.2 asir2.grao SOA
dig @10.144.144.2 asir2.grao NS
nslookup dnssrv.asir2.grao
nslookup ssh-server.asir2.grao
nslookup krb-cli.asir2.grao
##TESTEAR RESOLUCIÓN INVERSA
nslookup 10.144.144.2
nslookup <ip_kdc>
nslookup <ip_ssh-server>

Para verifira si nuestro fichero de zona es correcto y se carga correctamente podemos utilizar el comando named-checkzone Responde:

  1. Ejecuta y explica que hacen las consultad del comando dig anteriores
  2. ¿A que servidor de nombres realizamos la consulta si omitimos el parámetro @10.144.144.2?
  3. Investiga sobre el comando named-checkzonee indica el comando que ejecutarías para verificar que el fichero de zona asir2.grao es correcto

Kerberos

Instalación y configuración del servidor Kerberos(KDC)

$ incus launch images:ubuntu/noble kdc --network krb-net
$ incus exec kdc -- bash -c 'apt-get update && apt-get -y install  aptitude wget krb5-kdc krb5-admin-server dnsutils bash-completion nano xsel vim'

Al instalar el paquete krb5-kdc se nos pedira que introduzcamos información.

kdc-install01

Una vez instalado, será necesario configurar el servidor kerberos.

Creamos el realm y la base de datos de nuestros principals

$ krb5_newrealm

Creemos nuestro primer principal. Puesto que no hay ninguno creado deberemos usar la utilidad kadmin.local que usa un socket UNIX local para hablar con el KDC y requiere privilegios de root

$ sudo kadmin.local
Authenticating as principal root/admin@ASIR.GRAO with password.
kadmin.local: addprinc ubuntu
WARNING: no policy specified for ubuntu@ASIR.GRAO; defaulting to no policy
Enter password for principal "ubuntu@ASIR.GRAO": 
Re-enter password for principal "ubuntu@ASIR.GRAO": 
Principal "ubuntu@ASIR.GRAO" created.
kadmin.local: quit

Para poder usar kadmin de forma remota deberemos crear un principal administrador. Por convenio se sugiere que se utilice el tipo admin, de esta forma podemos crear reglas ACL genéricas de forma mas fácil.

$ sudo kadmin.local
Authenticating as principal root/admin@ASIR2.GRAO with password.
kadmin.local: addprinc ubuntu/admin
WARNING: no policy specified for ubuntu/admin@ASIR2.GRAO; defaulting to no policy
Enter password for principal "ubuntu/admin@ASIR2.GRAO": 
Re-enter password for principal "ubuntu/admin@ASIR2.GRAO": 
Principal "ubuntu/admin@ASIR2.GRAO" created.
kadmin.local: quit

A continuación, asignamos los permisos apropiados al usuario admin en el fichero /etc/krb5kdc/kadm5.acl:

ubuntu/admin@ASIR2.GRAO        *

Comprobamos que efectivamente podemos logearnos con el usuario ubuntu/admin

$ubuntu kadmin -p ubuntu/admin
kadmin: quit

Y solictar un tiquet TGT

$ubuntu kinit -p ubuntu/admin
$klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ubuntu/admin@ASIR2.GRAO

Valid starting       Expires              Service principal
01/28/2026 15:44:49  01/29/2026 15:44:49  krbtgt/ASIR2.GRAO@ASIR2.GRAO

Note

Las indicaciones anteriores se han basado en el siguiente tutorial de ubuntu. Revisalo en caso de tener problemas con la configuración del servidor kerberos.

Tip

kinit inspecciona el fichero /etc/krb5.conf para encontra con que KDC contactar. Esto tiene el inconveniente que en un despliege con cientos de clientes, si modificamos la ip del KDC deberemos reflejar ese cambio en el fichero. El KDC puede ser encontrado via busquedas DNS, para ello debes añadir registros TXT y SRV a tu servidor de nombres. Mejora tu calificación llevando la mejora mencionada.

Instalación y configuración del cliente

$ incus launch images:ubuntu/noble krb-cli --network krb-net
$ incus exec krb-cli -- bash -c 'apt-get update && apt-get -y install  aptitude wget krb5-user dnsutils krb5-config bash-completion nano xsel vim'

Completamos la instalación del paquete krb5-user introduciendo los valores para el REALM y el KDC

Comprobamos el correcto funcionamiento solicitando un tiquet

root@kdc-client:~# kinit ubuntu
root@kdc-client:~# klist
Password for ubuntu@ASIR22.GRAO: 
root@krb-cli2:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ubuntu@ASIR2.GRAO

Valid starting       Expires              Service principal
01/28/2026 15:51:09  01/29/2026 15:51:09  krbtgt/ASIR2.GRAO@ASIR2.GRAO

Responde:

  1. ¿Qué diferencias hay entre el comando kadmin.local y kadmin?,¿Por qué esa diferenciación?
  2. ¿Qué hace el comando addprinc?
  3. ¿Para que sirve el fichero /etc/krb5kdc/kadm5.acl? ¿Que significado tiene la regla?

*/admin@EXAMPLE.COM *

  1. Explica con tus propias palabra que hace el comando kinit y el comando klist

Instalación y configuración del servidor SSH Kerberizado

$ incus launch images:ubuntu/noble ssh-server --network krb-net
$ incus exec ssh-server -- bash -c 'apt-get update && apt-get -y install dnsutils krb5-user krb5-config openssh-server aptitude wget bash-completion nano xsel vim'
$ incus exec ssh-server -- bash -c 'systemctl enable sshd.service'

Al igual que el cliene completamos la instalación del paquete krb5-user introduciendo los valores para el REALM y el KDC y verificamos que podemos conectarnos con el servidor kdc

root@ssh-server-k:~# kinit ubuntu/admin
root@ssh-server-k:~# klist

Debemos crear un principal del servidor ssh en la base de datos del kdc y exportar dicha clave en un fichero que guardaremos en el servidorr ssh para que kerberos haga uso del mismo.

root@ssh-server:~# kadmin
kadmin: addprinc -randkey host/ssh-server.asir2.grao@ASIR2.GRAO
kadmin: listprincs
host/ssh-server.asir2.grao@ASIR2.GRAO
[..]
ubuntu/admin@ASIR2.GRAO
ubuntu@ASIR2.GRAO

##El comando ktadd copia la clave existente en la base de datos del _kdc_ al fichero /etc/krb5.ketyab necesaria para validar los tiquets
##presentados por el cliente
kadmin: ktadd host/ssh-server.asir2.grao
kadmin: quit
klist -ke /etc/krb5.keytab

Kerberiza el servidor ssh

Debemos configurar el servicio ssh para que este acepte tiquets presentados por el cliente.

Warning

Muy importante(Motivo por el que a algunos no les funcionaba correctamente) es asignar a nuestra servidor ssh el nombre completo FQDN, puesto que el servicio ssh se basa en este para generar el SPN que busca a posteriori en la base de datos de contraseñas del kdc.

Utilizaremos el siguiente comando para establecer el nombre completo.

hostnamectl set-hostname ssh-server.asir2.grao

Edita en el servidor ssh el fichero /etc/ssh/sshd_config y modifica

#/etc/ssh/sshd_config
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes

Edita en el cliente krb-cli fichero /etc/ssh/ssh_config

#/etc/ssh/ssh_config
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

Responde:

  1. ¿Explica el comando ktadd y situalo en el contexto de la práctica?,¿Por qué hay que usarlo?
  2. ¿Dentro del contexto de kerberos, que es un SPN, enumero un SPN usado en la práctica?
  3. Dentro del contexto de kerberos, define y ejemplifica con tus propias palabras los siguietes términos. Busca una analogia del mundo real asociando los términos:
    • TGS
    • TGT
    • TS
    • AS

Comprobación y depuración

Comprueba el correcto funcioamiento de la actividad solicitando desde el cliente un tiquet y accediendo al servidor ssh al cual debes acceder sin necesitdad de introducir contraseña.

krb-cli$ kinit ubuntu
krb-cli$ ssh ubuntu@ssh-server.asir2.grao

Depuración En caso de que la práctica no funciona como fuera de esperar es conveniente consutar los mensajes de depuración tanto del cliente como del servidor. Ejecuta en el servidor el servicio sshd en modo debug (muestra mensajes adicionales en la salida estandar) en un puerto diferente.

ssh-server$ /usr/sbin/sshd -d -d -d -p 2223

Y en el cliente conectate activando tambien el modo debug al nuevo puerto del servidor ssh.

krb-cli$ ssh -vv ubuntu@ssh-server.asir2.grao -p 2223

Observa los mensajes de ambos programas para obtener más información de por que kerberos no es capaz de autenticarse de forma correcta.

Entrega

Utiliza el formato markdown adecuado para tener un documento estructurado y legible.

Propuestas de mejora

Las siguientes propuestas de mejora de la práctica se plantean al alumno como reto para que mejore sus destrezas y conocimientos de las herramientas de administrdor de sistemas y mejore su nota en la asignatura.

Anexo I. Glosario de términos

Anexo II. Misc comands

incus network set incusbr0 dns.domain asir2.grao
getent hosts 10.149.165.99 
resolvectl dns <network interface> <dns_address>
resolvectl domain <network interfacee> ~<dns_domain>