Cómo restringir el acceso de los usuarios SSH a directorios específicos en Ubuntu 24.04

La forma más segura de restringir el acceso de los usuarios SSH a un directorio específico en Ubuntu 24.04 es usar OpenSSH ChrootDirectorycon ForceCommand internal-sftp. Esto es ideal cuando la cuenta solo necesita transferir archivos. Le proporciona al usuario una vista SFTP cuyo directorio raíz es el que usted elija, al tiempo que bloquea el acceso a una consola interactiva y el reenvío SSH.

Si el usuario realmente necesita una shell normal, la decisión es diferente. Una shell interactiva en un entorno chroot requiere su propio binario de shell, bibliotecas, nodos de dispositivo y archivos de soporte dentro del entorno aislado. OpenSSH lo documenta explícitamente. Para la mayoría de las cuentas de carga, copia de seguridad, agencia, proveedor y alojamiento compartido, un entorno chroot solo para SFTP es mucho más sencillo y menos propenso a errores. Para usuarios no confiables que necesitan un entorno de comandos completo, un contenedor o una máquina virtual dedicada suele ser más fácil de mantener que crear manualmente un entorno chroot para la shell.

Esta guía utiliza Ubuntu 24.04 LTS y un usuario de ejemplo llamado alice. El usuario tendrá acceso restringido /srv/sftp/alicey solo podrá escribir dentro de /files. Reemplace los nombres y las rutas según las necesidades de su servidor.

Antes de comenzar: comprenda la regla de propiedad.

El fallo más común de chroot se debe a los permisos. OpenSSH requiere que cada componente de la ChrootDirectoryruta sea propiedad de root y no tenga permisos de escritura para el grupo u otros usuarios . Este requisito se verifica incondicionalmente. Eso significa que no debe hacer /srv/sftp/aliceque tenga permisos de escritura alice.

En su lugar, haga que el directorio raíz de la jaula sea propiedad del usuario root y cree un directorio hijo con permisos de escritura:

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

Este diseño sigue el comportamiento documentado en el manual de Ubuntu 24.04sshd_config(5) . El mismo manual señala que internal-sftpno necesita archivos de tiempo de ejecución adicionales dentro del entorno chroot, por lo que es la mejor opción para una cuenta con transferencia de archivos restringida.

Paso 1: Verifique que el servidor OpenSSH esté instalado.

Instale el paquete del servidor si es necesario:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

La documentación oficial de OpenSSH de Ubuntu utiliza openssh-serverpara el paquete daemon y ssh.servicepara la administración del servicio. Consulte la guía de OpenSSH de Ubuntu Server .

Si se trata de una máquina remota y SSH es su única vía de acceso administrativo, mantenga abierta su sesión de administrador mientras realiza los cambios. Una configuración incorrecta de SSH puede impedirle el acceso.

Paso 2: Crea un grupo y agrega al usuario restringido.

Crea un grupo para usuarios restringidos. Si aliceya existe, agrégala únicamente a ella.

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

Si ya utilizas claves públicas SSH, continúa haciéndolo. La configuración chroot controla lo que sucede después de la autenticación ; no requiere que cambies de la autenticación por clave a la autenticación por contraseña.

Una regla basada en grupos suele ser mejor que un Match Userbloqueo independiente para cada cuenta. Mantiene la política centralizada. Una regla por usuario sigue siendo útil cuando se debe restringir a diferentes usuarios a diseños no relacionados.

Paso 3: Cree un entorno aislado (jail) propiedad del usuario root y un subdirectorio con permisos de escritura.

Cree la jerarquía de directorios:

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

Verificar la propiedad:

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

Si /srvla /srv/sftpruta es modificable por el grupo o por el usuario, corríjala también. OpenSSH comprueba todos los componentes de la ruta, no solo el directorio final.

Paso 4: Añada una regla de coincidencia en sshd_config.d

La documentación actual del servidor Ubuntu recomienda mantener la configuración SSH personalizada en /etc/ssh/sshd_config.d/lugar de mezclarla con el archivo principal del paquete. Crea un fragmento:

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

Agregar:

Match Group sftpusers
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /files
    DisableForwarding yes
    PermitTTY no

Match all

%uSe expande al nombre de usuario autenticado, por lo que alicese coloca en /srv/sftp/alice. El -d /filesargumento le indica al servidor SFTP interno que se inicie dentro del directorio secundario escribible. DisableForwarding yesDeshabilita el reenvío de X11, agente, TCP y StreamLocal en una directiva; está documentado específicamente para simplificar configuraciones restringidas.

El carácter final Match alles importante en un fragmento porque finaliza el contexto condicional antes de que se analice la configuración posterior.

Paso 5: Decida entre restricciones basadas en grupos y restricciones por usuario.

Para varios usuarios con el mismo diseño, mantenga la regla de grupo que se muestra arriba. Para una única cuenta excepcional, utilice un bloque específico para ese usuario:

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

Elija en función del coste administrativo:

Paso 6: Validar la configuración SSH antes de reiniciar.

Nunca reinicies SSH inmediatamente después de editar el archivo. Primero ejecuta la prueba de sintaxis recomendada por Ubuntu:

sudo sshd -t

Si no se muestra ninguna salida, significa que la comprobación de sintaxis se realizó correctamente. También puede inspeccionar la configuración efectiva para un usuario en particular:

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

Deberías ver la ruta chroot esperada y el comando SFTP forzado. Esto es especialmente útil en Ubuntu porque la configuración puede provenir de /etc/ssh/sshd_configarchivos tanto como en /etc/ssh/sshd_config.d/. Ubuntu señala que OpenSSH generalmente usa el primer valor obtenido para la mayoría de las directivas, por lo que verificar la configuración efectiva es más seguro que asumir qué archivo prevalece.

Paso 7: Reinicie SSH y pruebe con SFTP.

Aplicar el cambio:

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

Luego conéctese desde otra terminal:

sftp alice@server.example.com

Dentro de SFTP, prueba:

pwd
ls
put test.txt
ls -l

Con la configuración anterior, el directorio SFTP inicial debería ser /files. La barra diagonal que muestra SFTP es la raíz del chroot, no la raíz real del servidor.

Un intento normal de acceso a la consola no debería producir una consola sin restricciones:

ssh alice@server.example.com

Dado que ForceCommand internal-sftpreemplaza la sesión solicitada con el servidor SFTP en proceso, esta cuenta está destinada intencionadamente a la transferencia de archivos en lugar de a la ejecución de comandos.

Paso 8: Confirmar que el usuario no puede escapar de la cárcel.

Intenta moverte por encima de la raíz aparente e inspecciona las rutas de host sensibles:

cd ..
ls /
ls /etc
ls /root

Dentro del chroot, /representa /srv/sftp/aliceen el host. Si no creaste ningún etcdirectorio rootdentro de esa jaula, el usuario no puede acceder al host real /etco /root.

Pruebe también una carga en /files. Una configuración que bloquea el escape pero que accidentalmente convierte todo el entorno aislado en de solo lectura es segura pero no útil para una cuenta de carga.

Solución de problemas: “Propiedad o modos incorrectos para el directorio chroot”

Si el inicio de sesión falla inmediatamente, revise el registro del servicio SSH:

sudo journalctl -fu ssh.service

La guía de OpenSSH de Ubuntu recomienda el registro del servicio SSH para la resolución de problemas. Si ve un error de propiedad o de modo, inspeccione cada directorio padre:

namei -l /srv/sftp/alice

La ruta chroot debe pertenecer al usuario root y no debe ser modificable por el grupo ni por otros usuarios. Un error común es el siguiente:

sudo chown alice:alice /srv/sftp/alice

No resuelva el problema debilitando las comprobaciones de OpenSSH. En su lugar, coloque el área de escritura del usuario debajo de la raíz de chroot:

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

¿Qué ocurre si el usuario necesita acceso a la consola SSH, y no solo SFTP?

ChrootDirectoryTambién se puede usar con un intérprete de comandos interactivo, pero la configuración es considerablemente más compleja. OpenSSH indica que un entorno chroot interactivo requiere al menos un intérprete de comandos y /devnodos básicos, además de los binarios, bibliotecas, archivos de resolución de nombres y demás dependencias necesarias para los comandos permitidos.

Para una cuenta de dispositivo con control estricto, la creación de un entorno aislado (jail) puede estar justificada. Sin embargo, para el acceso general a comandos de Linux, suele generar una carga de mantenimiento: las actualizaciones de seguridad de las herramientas y bibliotecas también deben reflejarse dentro del entorno aislado. Si su requisito real es "permitir que esta persona ejecute comandos, pero aislándola del host", un contenedor, una máquina virtual o un servicio restringido diseñado específicamente para ello suele ser más fácil de auditar.

Mejoras de seguridad que vale la pena añadir

La restricción de directorios es solo una capa. Para servidores con acceso a Internet, considere también:

• Utilice la autenticación de clave pública SSH para cuentas humanas y de automatización siempre que sea posible.
• No otorgue sudoacceso a usuarios con permisos restringidos para la transferencia de archivos.
• Manténgalo DisableForwarding yespara cuentas exclusivas de SFTP para que la conexión SSH no pueda reutilizarse para túneles o reenvío de agentes.
• Limite los directorios con permisos de escritura al área mínima que necesite el flujo de trabajo.
• Revisar journalctl -u ssh.servicey gestionar la propiedad de los archivos después de agregar usuarios.
• Mantenga abierta una sesión de administrador mientras prueba los cambios de configuración SSH remotos.

Para conocer el comportamiento definitivo de ChrootDirectory, Match, ForceCommand, y DisableForwarding, consulte el manual de configuración del servidor OpenSSH de Ubuntu 24.04 . Para obtener información sobre la configuración específica de Ubuntu, la validación, los comandos de reinicio y el registro, consulte la documentación oficial del servidor OpenSSH de Ubuntu .

En resumen

Si el objetivo es que “esta cuenta SSH solo pueda cargar y descargar archivos dentro de un directorio”, use un directorio propiedad del usuario root ChrootDirectory, coloque el contenido modificable en un subdirectorio propiedad del usuario y fuerce la carga internal-sftp. Valide con sshd -tantes de reiniciar y luego pruebe tanto la ruta de carga permitida como el intento de acceso fuera del entorno aislado. Esto le brinda un límite de seguridad pequeño y comprensible sin tener que construir un entorno Linux completo dentro del entorno aislado.