Configuración de servidores SSH en contenedores para la grabación de sesiones con tlog

En la primera parte de esta serie, destaqué algunos de los beneficios de la grabación de sesiones y el uso de servidores SSH en contenedores. También mostré una arquitectura de alto nivel. Como paso preparatorio, se configuró uno de los servidores con RHEL 8.2 para compilar y alojar los contenedores sin raíz del servidor SSH.

Después de preparar el servidor y crear el usuario (tester2 ), creamos un Dockerfile personalizado para el servidor SSH con la grabación de sesiones configurada.

En el siguiente Dockerfile, utilizamos la imagen ubi-init (multiservicio), que admite systemd y tiene el CMD /sbin/init como predeterminado para iniciar el systemd servicio de inicio. Se hacen las siguientes suposiciones para esta configuración.

• El servicio expone el puerto 2022 en lugar del 22 dentro de un contenedor para SSH
• Configure tres usuarios (es decir, tester , tester2 y tester3 )
• Utilice el mismo UID para el usuario contenedor tester como usuario (tester2 ) ejecutando el contenedor sin raíz en el host para que este usuario pueda ser root dentro del contenedor
• Cambiar UID para tester dentro del contenedor como 0 (raíz)
• Configure las claves SSH como argumentos de compilación para el usuario tester y tester2 y un inicio de sesión basado en contraseña para tester3
• Configurar la grabación de sesiones para los usuarios tester2 y tester3 configurando el shell de inicio de sesión como /usr/bin/tlog-rec-session
• Asignar volúmenes persistentes para /home y /var/log/journal durante la creación del contenedor para conservar los directorios de inicio de los usuarios y el servicio SSH y los registros de grabación de sesiones
• Copie el tlog-rec-session.conf desde el host al contenedor con la siguiente configuración para capturar registros de grabación de sesiones usando journald :

{"shell":"/bin/bash","notice":"\nATTENTION! Your session is being recorded!\n\n","latency":10,"payload":2048,"log":{"input":false,"output":true,"window":true},"limit":{"rate":16384,"burst":32768,"action":"pass"},"file":{"path":""},"syslog":{"facility":"authpriv","priority":"info"},"journal":{"priority":"info","augment":true},"writer":"journal"}

[ Pruebe la grabación de sesiones en un laboratorio en vivo: Configuración de la grabación de sesiones de terminal]

Dockerfile para contenedor SSH

Aquí hay un Dockerfile de muestra para el contenedor SSH:

FROM ubi8/ubi-init

ARG ADMIN_PUBLIC_KEY
ARG TESTER2_PUBLIC_KEY

RUN yum -y install openssh-server ed openssh-clients tlog glibc-langpack-en && yum clean all && systemctl enable sshd;
RUN sed -i 's/#Port.*$/Port 2022/' /etc/ssh/sshd_config && chmod 775 /var/run && rm -f /var/run/nologin
RUN mkdir /etc/systemd/system/sshd.service.d/ && echo -e '[Service]\nRestart=always' > /etc/systemd/system/sshd.service.d/sshd.conf

COPY tlog-rec-session.conf /etc/tlog/tlog-rec-session.conf
RUN adduser --system -s /bin/bash -u 1001 tester && \ #UID matching user uid on host
           adduser --system -s /usr/bin/tlog-rec-session -u 1000 tester2 && \
           adduser --system -s /usr/bin/tlog-rec-session -u 1002 tester3 -p y5utxaxUDNFII && \
           mkdir -p /home/tester/.ssh /home/tester2/.ssh /home/tester3/.ssh

RUN touch /home/tester/.ssh/authorized_keys /home/tester2/.ssh/authorized_keys /home/tester3/.ssh/authorized_keys && \
           chmod 700 /home/tester/.ssh /home/tester2/.ssh /home/tester3/.ssh && \
           chmod 600 /home/tester/.ssh/authorized_keys /home/tester2/.ssh/authorized_keys /home/tester3/.ssh/authorized_keys && \
           sed -i 's/1001/0/g' /etc/passwd && \ #Update UID with root UID
           echo ${ADMIN_PUBLIC_KEY} >> /home/tester/.ssh/authorized_keys && \
           echo ${TESTER2_PUBLIC_KEY} >> /home/tester2/.ssh/authorized_keys && \
           chown -R tester2:tester2 /home/tester2/ && chown -R tester3:tester3 /home/tester3/ && chown -R tester:tester /home/tester
LABEL Description="This ssh server is running systemd with rootless podman"
EXPOSE 2022

CMD ["/sbin/init"]

Guarde el archivo en el directorio de inicio como sshdockfile. Copie el /etc/tlog/tlog-rec-session.conf predeterminado al directorio de inicio.

Crear la imagen del contenedor

Para construir la imagen del contenedor con las claves deseadas, genere un nuevo par de claves para el usuario. A continuación, exporte la clave pública predeterminada y la recién creada como variables. Finalmente, páselos como argumentos de construcción usando lo siguiente. Este es el proceso:

# ssh-keygen-t ecdsa ; ssh-keygen -t ecdsa -f .ssh/tester2

# export ADMIN_PUBLIC_KEY=`cat /home/test2/.ssh/id_ecdsa.pub`

# export TESTER2_PUBLIC_KEY=`cat /home/test2/.ssh/tester2.pub`

# podman build -t testsshd -f sshdockfile --cgroup-manager=cgroupfs --build-arg ADMIN_PUBLIC_KEY="$ADMIN_PUBLIC_KEY" --build-arg TESTER2_PUBLIC_KEY="$TESTER2_PUBLIC_KEY"

El cgroup-manager El argumento requiere cgroups-v2 y es necesario para que el contenedor sin raíz use systemd exitosamente. Podman informa el siguiente error a menos que se pase este argumento:

systemd cgroup flag passed, but systemd support for managing cgroups is not available: OCI runtime error

Si la compilación tiene éxito, el siguiente paso es ejecutar el contenedor con los volúmenes persistentes deseados. Estos volúmenes (para /var/log/journal y /home ) son creados previamente o Podman los crea dinámicamente en el volume directorio bajo la ubicación de almacenamiento predeterminada (podman info | grep -i graphroot ).

Ejecutar el servidor SSH

Como los contenedores sin raíz no admiten complementos CNI para redes, se asigna un puerto superior preferido (>1024) para exponer el servicio SSH.

# podman run -d --name=rootless_ssh1 -v ssh1home:/home:Z -v ssh1logs:/var/log/journal:Z -p 33000:2022 --cgroup-manager=cgroupfs localhost/testsshd

Probar acceso SSH

Desde la máquina host, inicie sesión en el servidor SSH usando las claves SSH para usuarios tester y tester2 y la contraseña (redhat123 ) para tester3 .

# ssh -l tester -i /home/test2/.ssh/id_ecdsa localhost -p 33000

# ssh -l tester2 -i /home/test2/.ssh/tester2 localhost -p 33000

# ssh -l tester3 localhost -p 33000

Aparece un mensaje de que la sesión se está grabando para tester2 y tester3 .

Validar grabación de sesión

Después de iniciar sesión como testuser2 y testuser3 y ejecutando algunos comandos, hay tlog entradas en el archivo de registro diario. Como el tester usuario, ejecute el siguiente comando dentro del contenedor:

# journalctl | grep tlog-rec-session

Cada tlog la entrada tiene una ID de host, una ID de registro y un usuario asociado. Por ejemplo:

"host":"0ce2921675b0","rec":"26b55a3aafd94f40b49473ac33bd2c96-42-f99b3","user":"tester2"

Estas entradas de registro también son accesibles desde el host usando el volume ubicación:

/home/test2/.local/share/containers/storage/volumes/ssh1logs/_data/<containerid>/system.journal

Puede haber más de un directorio en ssh1logs/_data si el (los) contenedor(es) anterior(es) ha(n) sido terminado(s) y uno nuevo lo reemplazó.

Reproducir una sesión grabada

El tlog-play El comando admite la reproducción de una sesión. Por lo general, el administrador está interesado en reproducir una sesión de usuario específica. Para lograrlo, exporte las entradas de sesión para esa sesión en particular desde los registros del diario y guárdelas en un archivo local.

Identifique un ID de registro específico y utilícelo para filtrar todos los registros con el siguiente awk comando:

# journalctl --file .local/share/containers/storage/volumes/ssh1logs/_data/<containerid>/system.journal | awk -F '{"' '$0~/<tlog record id>/{ print "\{\"" $2 }' 2>/dev/null > ~/session_recording.log

# tlog-play -r file -i ~/session_recording.log

De esta manera, los administradores pueden segregar y almacenar los registros de sesión específicos para cada sesión de usuario y reproducirlos a pedido. Estos registros de sesión también se pueden enviar a una ubicación central para fines de auditoría. Por defecto, tlog no captura la entrada estándar para el usuario, por lo que la información confidencial, como las contraseñas, no se captura ni se almacena en los registros.

Se puede ejecutar más de un servidor SSH en contenedores simultáneamente en el host (usando diferentes asignaciones de puertos), y cada uno de los contenedores tiene perfiles de usuario separados y asignaciones de volúmenes persistentes separadas. Los propios contenedores también se pueden configurar como systemd servicios en el host para iniciarlos en el arranque.

Resumir

Presentamos Red Hat IDM y servidores backend (integrados con IDM) en la siguiente parte. Control de acceso basado en host y sudo centralizado se configurará para usuarios/grupos de IDM para administrar qué usuarios pueden ejecutar qué comandos en qué hosts.

[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]