El producto de nuestra empresa es una aplicación que se ejecuta en un contenedor. Escucha en el puerto 2222 para establecer una interfaz de línea de comando.
Un cliente tiene problemas con SSH, nunca antes habíamos visto este problema y no podemos reproducir exactamente con el mismo sistema operativo (RHEL 7.8), versión de Docker (RHEL empaquetado 1.13.1) + contenedor (nuestra aplicación, misma versión).
Cuando lo hacen:
ssh -p 2222 <user>@<ip>
Los errores que ven en el lado del cliente son:
server refused to allocate ptyoPTY allocation request failed on channel 0
Los registros de errores dentro de nuestra aplicación (servidor) son:
openpty: Operation not permitted
session_pty_req: session 0 alloc failed
pam_unix(sshd:session): session closed for user <>
Al buscar esto en Google, una posibilidad son permisos incorrectos en: /dev/pts, o /dev/pts/ptmx, o /dev/ptmx. Pero aquí tienen razón.
Otra posibilidad es que al montaje de devpts le falte gid=5. Revisé y los montajes parecen correctos tanto en el host como en el contenedor.
# Host
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
# Container
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
He comparado mi sistema con el del cliente. Todo parece coincidir, pero obviamente algo anda mal.
Otro punto de datos: actualmente ejecutan el contenedor usando docker run --user 100001:0 ...donde user-id=1000001, group-id=0 o root. Si, en cambio, ejecutan el contenedor como root docker run --user 0:0 ..., este problema no ocurre. Es un problema de permisos en alguna parte.
¿Alguien encontró esto antes?
Cualquier sugerencia sería muy apreciada ya que no tengo ideas.
Respuesta1
Descubrimos que el problema era que el NIS del cliente estaba configurando tty en el grupo 7.
Configuramos strace en el proceso ssh dentro del contenedor. Cuando intentan ingresar por ssh, openpty() intentará chown y fallará, vemos esto en los registros de strace:
chown("/dev/pts/0", 1000001, 7) = -1 EPERM (Operation not permitted)
Luego, cuando lo hicimos, getent group | grep ttyvimos que NIS estaba configurando tty en el grupo 7.
Este error no ocurrirá si el contenedor se estaba ejecutando como root (--usuario no especificado en la ejecución de la ventana acoplable) o si el contenedor de la ventana acoplable no utiliza la red del host.
Para solucionar este problema, debemos asegurarnos de que la configuración de NIS no se filtre en el contenedor, así que edite /etc/nsswitch.conf dentro del contenedor y elimínelo nispara las entradas passwd, shadowy group.
Ahora, cuando se inicie la sesión ssh, /dev/pts/<> en el contenedor se creará con el grupo de contenedores (el "correcto"), y chown no debería fallar.