Cómo restringir el acceso de los usuarios SSH a directorios específicos en Ubuntu 24.04 (Guía de Chroot SFTP)

Otorgar a un contratista acceso para subir algunos archivos no debería darle automáticamente una sesión de terminal con acceso a todo el servidor. En Ubuntu 24.04 LTS, OpenSSH puede restringir una cuenta de transferencia de archivos a un directorio específico mediante una ChrootDirectoryregla y el servidor integrado internal-sftp. Es importante destacar que esta restricción se aplica únicamente a SFTP , no es una forma sencilla de proporcionar una consola Bash completamente funcional pero restringida.

Esta guía explica qué protegen realmente las configuraciones y luego describe una configuración reversible de ocho pasos para varias cuentas, cada una con su propio directorio. Los comandos utilizan una cuenta de ejemplo llamada contractory un host de ejemplo llamado server.example.com; reemplácelos con sus propios valores. Estos son ejemplos de configuración, no resultados reales de una prueba en un servidor real.

¿Qué tipo de restricción necesitas realmente?

Tres controles suelen confundirse. Los permisos de Linux determinan qué archivos puede leer o modificar una cuenta; cambiar el directorio personal de la cuenta establece una ubicación inicial; un entorno chroot cambia la raíz del sistema de archivos que se presenta a un proceso. No son intercambiables.

Idea errónea: establecer /home/contractorun directorio como directorio principal limita al usuario a ese directorio. No es así. Un usuario normal de la línea de comandos puede moverse a cualquier directorio accesible en el sistema de archivos. Si el intercambio de archivos es realmente necesario, elija la opción SFTP que se describe a continuación en lugar de intentar ocultar directorios con la línea de comandos.

Documentos de OpenSSH ChrootDirectory, Matchy ForceCommanden el manual oficial de sshd_config de Ubuntu 24.04 .

Configura un entorno aislado de directorio solo para SFTP en ocho etapas.

Antes de modificar SSH de forma remota, mantenga abierta su sesión de administrador y asegúrese de tener acceso a la consola o al servidor de recuperación. Utilice una cuenta independiente sin privilegios para las transferencias; no añada su cuenta de administrador al grupo restringido.

1. Verifique OpenSSH y mantenga una sesión de recuperación.

En el servidor, instale OpenSSH si es necesario, verifique el servicio y guarde la configuración principal. La documentación oficial del servidor de Ubuntu admite estas rutas de servicio y configuración.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Si solo puede administrar la máquina mediante SSH, no cierre la sesión actual mientras edita o realiza pruebas. Consulte la guía de configuración del servidor Ubuntu OpenSSH antes de modificar el demonio.

2. Cree un usuario dedicado y un grupo de acceso SFTP.

Un grupo resulta útil cuando se prevé más de una cuenta restringida. Este ejemplo asigna a cada miembro un entorno aislado (jaul) independiente mediante el %utoken, que OpenSSH expande al nombre de usuario que se conecta. La /uploadruta de inicio debe estar dentro del entorno chroot, por lo que no es necesario crear un /uploaddirectorio a nivel de host.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

El adduserproceso puede solicitarle que asigne una contraseña. En instalaciones que deshabilitan la autenticación por contraseña SSH, cree y autorice una clave pública; no active el inicio de sesión con contraseña globalmente solo por seguir un ejemplo. El nologinintérprete de comandos es otra medida de seguridad, pero el internal-sftpcomando forzado es lo que hace que esta configuración sea de solo transferencia. Pruebe la combinación en su propio sistema de autenticación.

3. Cree un directorio chroot propiedad del usuario root.

Aquí es donde muchas guías se equivocan. OpenSSH requiere que cada componente de la ruta chroot pertenezca al usuario root y que otros usuarios o grupos no tengan permisos de escritura. Nunca permita que la cuenta SFTP tenga permisos de escritura para la propia raíz del entorno aislado (jail).

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

Compruebe también los componentes existentes /; /srvlos comandos anteriores no corrigen automáticamente los permisos de los padres que no son seguros. Si algún componente es modificable por el grupo o pertenece al usuario, corrija su propiedad y modo solo después de comprobar si otras aplicaciones dependen de él.

4. Agregue un subdirectorio con permisos de escritura dentro del entorno aislado (jail).

La cuenta puede escribir en un directorio secundario sin tener permiso para modificar la raíz chroot. Cree /srv/sftp/contractor/uploadpara los archivos reales de la cuenta; desde dentro de SFTP, esto aparecerá como /upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

La propiedad esperada difiere deliberadamente: root:rootpara la raíz del jail y contractor:contractorpara la carpeta de carga con permisos de escritura. Evite chmod 777, ya que introduciría una exposición innecesaria y sería rechazado si se aplicara a la raíz del jail.

5. Agregue una regla de coincidencia a sshd_config.

Abra /etc/ssh/sshd_configy agregue el siguiente bloque al final, después de cualquier directiva y Matchbloque existente. Use un editor de texto como sudoedito sudo nano. Revise Matchprimero las reglas existentes: si varios bloques coincidentes asignan la misma palabra clave, OpenSSH usa la primera instancia aplicable. Ubuntu también procesa archivos en /etc/ssh/sshd_config.d/desde un inicio Include; las reglas allí pueden afectar la precedencia.

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

Match Groupapunta a los miembros de sftpclients. ChrootDirectorycoloca a cada usuario bajo /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadejecuta un servicio SFTP en proceso y se inicia dentro del directorio escribible. PermitTTY noimpide la asignación de terminal, mientras que DisableForwarding yesdesactiva las funciones de reenvío SSH para las conexiones coincidentes.

Mantén la Subsystem sftpdirectiva global que ya proporciona Ubuntu, a menos que tengas un motivo específico para modificarla; el comando SFTP interno forzado no requiere reemplazar esa línea global. No añadas una directiva global adicional Match Allsolo para finalizar un bloque sin comprender sus consecuencias.

6. Compruebe la sintaxis y la configuración efectiva antes de recargar.

El éxito del análisis no prueba que los permisos de la jaula sean correctos, ni tampoco prueba que la cuenta prevista coincida con la política. Realice ambas comprobaciones explícitamente.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

La configuración efectiva debe especificar la ruta chroot deseada, el comando SFTP forzado, la asignación de TTY deshabilitada y las restricciones de reenvío. La dirección de ejemplo 192.0.2.10es solo para fines de documentación; si tiene Matchreglas que dependen de la dirección, sustitúyala por la dirección de origen real del cliente. El -T -Cformato se documenta en el manual de sshd de Ubuntu 24.04 .

Si la validación falla, corrija la configuración antes de reiniciar SSH. Si los valores efectivos son inesperados, revise los fragmentos incluidos y el orden de los bloques condicionales existentes, no solo las últimas líneas que editó.

7. Reinicie SSH y conserve su acceso de administrador.

Tras realizar las comprobaciones correctamente, reinicie el servicio SSH para que las nuevas conexiones utilicen la política modificada. Mantenga activa la conexión de administrador actual mientras abre una segunda terminal para confirmar que el acceso de administrador normal sigue funcionando.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Un reinicio completo también puede aplicar los cambios, pero es preferible recargar la aplicación cuando sea posible y se desee evitar interrupciones innecesarias. La salida de los comandos de servicio y los mensajes de registro varían según el host, por lo que conviene revisar el resultado real en lugar de asumir que un retorno exitoso al indicador de comandos garantiza el acceso.

8. La prueba permitió transferencias y bloqueó el acceso a la consola.

Desde otro ordenador, conéctese como usuario restringido. Utilice el nombre de host real del servidor y un archivo de prueba adecuado. El primer directorio SFTP debe ser /upload, y la raíz chroot debe aparecer como /en lugar de la ruta del host /srv/sftp/contractor.

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

Se debería permitir subir un archivo de prueba inofensivo /upload. No debería ser posible acceder al directorio raíz del host /etc: el entorno chroot define un directorio raíz diferente, al que /etcsolo se podría acceder si se creara o expusiera deliberadamente dicho directorio dentro del entorno aislado. El texto exacto del error del cliente no es importante.

ssh contractor@server.example.com

No se debe abrir una consola SSH interactiva normal para esta cuenta. En su lugar, la conexión podría cerrarse o mostrar un mensaje relacionado con el protocolo; no se fíe de una frase exacta. Si se abre una consola, considere la configuración como insegura y revise la pertenencia a grupos, Matchla precedencia y sshd -T -Cla salida efectiva antes de usar la cuenta.

¿Qué ocurre si utilizas claves públicas SSH?

La autenticación de clave pública funciona con un entorno aislado SFTP, pero ubicar el directorio principal del host del usuario en /uploaduna ruta predeterminada ~/.ssh/authorized_keyspuede impedir que exista fuera de dicho entorno. Una alternativa práctica es permitir que SSH lea un archivo de clave controlado por el usuario root antes de iniciar el entorno chroot. Agregue esto dentro del mismo Match Group sftpclientsbloque si elige el almacenamiento centralizado de claves:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Luego, cree un archivo /etc/ssh/authorized_keys/contractorque contenga la clave pública autorizada del contratista, con la propiedad de root y sin permisos de escritura para el grupo o para todos los usuarios. Por ejemplo, después de copiar de forma segura un archivo de clave pública verificado con el nombre especificado contractor.puba un directorio de preparación administrativa:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

No copie una clave privada en el servidor. La configuración de la ruta de la clave, los valores predeterminados de autenticación y las comprobaciones de cuenta dependen de su política SSH actual; verifique el acceso mediante clave pública antes de deshabilitar un método de autenticación que ya funciona.

Fallos comunes y qué significan

Compruebe los registros con sudo journalctl -u ssh -n 80 --no-pager. El error exacto depende de la configuración de PAM, la configuración de SSH, el acceso al sistema de archivos y el método de autenticación. OpenSSH 9.0 y versiones posteriores utilizan SFTP para scplas transferencias estándar de forma predeterminada, mientras que el modo heredado requiere un shell, como se explica en el manual de scp de Ubuntu 24.04 .

¿Es posible restringir el acceso a una consola SSH interactiva a una sola carpeta?

No con un cambio de directorio de inicio ni con el ejemplo anterior que solo usa SFTP. OpenSSH ChrootDirectorytambién se puede usar para sesiones de shell, pero el entorno debe incluir un shell funcional, sus bibliotecas compartidas, los nodos de dispositivo necesarios y cualquier dependencia de comandos. Crear ese entorno de forma segura requiere más que simplemente configurar una línea sshd_config. Es fácil crear una configuración frágil o engañosa, especialmente cuando se utilizan comandos de shell o montajes arbitrarios.

Si un usuario realmente necesita comandos interactivos, primero especifique con exactitud qué comandos y archivos requiere. Para un conjunto reducido de comandos, utilice comandos remotos con un alcance limitado o un punto final de aplicación dedicado. Para entornos independientes más amplios, considere un contenedor o una máquina virtual con montajes de sistema de archivos explícitos, controles de privilegios y restricciones de red. Un entorno chroot por sí solo no sustituye el aislamiento completo del sistema, y ​​ni chroot ni los permisos de archivo de Unix protegen contra un usuario con privilegios que pueda modificar el sistema subyacente.

Lista de verificación de seguridad antes de otorgar acceso

• La cuenta de transferencia no es de administrador y pertenece únicamente a los grupos necesarios.
• Cada componente que conduce a la cárcel es propiedad del usuario root y no puede ser modificado por el grupo ni por otros usuarios.
• La ubicación de carga con permisos de escritura se encuentra dentro del entorno aislado (jail), no en la raíz del entorno aislado propiamente dicha.
• El usuario previsto coincide con ChrootDirectory, ForceCommand internal-sftp, y ha deshabilitado el reenvío en la configuración efectiva.
• La carga mediante SFTP se realiza correctamente, pero el intento de acceder a archivos restringidos al host falla, y el acceso normal a la consola SSH está bloqueado.
• Las copias de seguridad, la retención, las cuotas, la supervisión y la revocación de cuentas se gestionan por separado; un entorno aislado de directorio no implementa estas políticas automáticamente.

Para obtener información técnica más detallada, consulte la referencia de configuración de OpenSSH de Ubuntu 24.04 y el manual del servidor SFTP de Ubuntu . Estas instrucciones están dirigidas a Ubuntu 24.04 LTS; las compilaciones de paquetes y los fragmentos de código SSH existentes pueden modificar el comportamiento, por lo que la configuración y las pruebas de conexión en su propio equipo son las que toman las decisiones finales.