Generalmente, después de iniciar sesión exitosamente sftpy ejecutar un putcomando, esperaría que mi archivo se transfiera al $HOMEdirectorio del usuario que inició sesión. Esto funciona de inmediato, pero me gustaría restringir al sftpusuario a su $HOMEdirectorio (para que no pueda cdsubir más niveles, por ejemplo).
Aquí es donde estoy usando ChrootDirectory, según la documentación (https://linux.die.net/man/5/sshd_config)
ChrootDirectory: especifica una ruta a chroot(2) después de la autenticación. Esta ruta, y todos sus componentes, deben ser directorios de propiedad raíz en los que ningún otro usuario o grupo pueda escribir.
Creo que configuré las carpetas/permisos correctamente. Creo que la siguiente oración de la documentación no funciona o no se comporta como se esperaba.
Después del chroot, sshd(8) cambia el directorio de trabajo al directorio de inicio del usuario.
Después de modificarlo sshd_configpara usarlo ChrootDirectoryy acceder con éxito al servidor a través sftpdel directorio de trabajo del usuario, NO está configurado en el directorio $HOME del usuario, en realidad está configurado en un nivel superior. (por ejemplo, /homeen lugar de /home/userTest) La solución obvia para el usuario es ingresar al directorio correcto un nivel más abajo, pero si está utilizando algún sistema automatizado que simplemente envía datos por FTP al directorio de trabajo actual, esto puede ser muy problemático.
Primero mostraré el caso general y luego lo modificaré para mostrar cómo cambia el comportamiento del directorio de trabajo predeterminado una vez que ChrootDirectoryse introduce.sshd_config
Esto funciona como se esperaba:
- Cree el usuario (úselo
-mpara crear el directorio de inicio de este usuario):sudo useradd -m userTest - Dale al usuario una contraseña:
sudo passwd userTest - Nota
userTestdirectorio $HOME:cat /etc/passwd->userTest:x:1002:1004::/home/userTest:/bin/sh - sftp a su servidor para el usuario que acaba de crear:
sftp userTest@<your-server> - Tenga en cuenta el directorio de trabajo después de iniciar sesión correctamente:
pwd->Remote working directory: /home/userTest
El ejemplo anterior funciona exactamente como se esperaba, el único problema es userTestque no está bloqueado en el directorio de trabajo y puede cd ..restablecer el sistema de archivos.
Varias guías han tenido la misma solución básica a este problema (https://linuxconfig.org/how-to-setup-sftp-server-on-ubuntu-20-04-focal-fossa-linux)
Complementando los pasos anteriores
- Agregue un grupo sftp (esto se usará como clave para nuestro
Matchbloque ensshd_config):sudo addgroup sftp - Agregar
userTestusuario al grupo:sudo usermod -a -G sftp userTest - Editar
sshd_config:sudo nano /etc/ssh/sshd_config - Agregue las siguientes líneas al final del archivo.
Match group sftp
ChrootDirectory /home
ForceCommand internal-sftp
(Esto básicamente significa que cualquier usuario que pertenezca al sftpgrupo estará sujeto a las reglas ChrootDirectoryy ForceCommand)
Guarde el archivo y reinicie ssh: sudo systemctl restart ssh
Verifique que el directorio especificado ChrootDirectorycumpla con los requisitos de la documentación anterior: ls -ltr-> drwxr-xr-x 4 root root 4096 Jun 10 09:02 home(creo que esto pasa)
Compare los resultados de la configuración lista para usar con los de nuestra nueva configuración sftp usando userTestnuevamente:sftp userTest@<your-server>
Tenga en cuenta el directorio de trabajo actual: pwd->Remote working directory: /
Esto no es un indicio de que algo anda mal, esperamos que el directorio de trabajo cambie... sin embargo, revisemos rápidamente el contenido del directorio de trabajo actual:
ls -ltr-> drwxr-x--- 3 1002 1004 4096 Jun 10 09:10 userTest(!!!)
Según la documentación:
Después del chroot, sshd(8) cambia el directorio de trabajo al directorio de inicio del usuario.
ls -ltrnos muestra que el directorio de trabajo NO está en el userTestdirectorio de inicio, en realidad está un nivel ARRIBA.
¿Hay alguna forma de configurarlo ChrootDirectoryo alguna otra forma de hacer que esto funcione como se esperaba?
NOTA: ¿La eliminación ForceCommandde sshd_config en realidad causa este otro problema que se cerró como ERRATA hace 11 años?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=681202