compartir clave pública ssh en la configuración de sftp

Question

He configurado un servidor SFTP en CentOS siguiendoeste doctor. Mi intención es prohibir el inicio de sesión en la consola para los nuevos usuarios ( user1, user2), que pertenecen al sftpusersgrupo, pero aún pueden iniciar sesión en sus respectivas sftpcarpetas.

Además, quiero usar las mismas claves que usa el usuario de CentOS (que puede iniciar sesión en la consola y sftpsin problemas). Para hacer eso, copié la .sshcarpeta del usuario de CentOS a las carpetas de inicio user1y user2, cambiando la propiedad a los usuarios, 700a la .sshcarpeta y 600al authorized_keysarchivo.

Aún así sigo recibiendo el mensaje Server refused our key. La clave que usa el usuario de CentOS es como una clave maestra en todos los servidores, por eso quiero reutilizar esa clave para los nuevos usuarios.

¿Cómo puedo lograr esta configuración?

ACTUALIZAR

Después de generar claves para cada usuario, ambos usuarios pueden acceder al servidor de forma remota con sus claves privadas, pero cuando activo la siguiente configuración en /etc/ssh/sshd_configlos permisos se deniegan usando el sftpcomando.

Configuración SSHD

Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp

Mensaje del caparazón

packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer

Answer 1

La actualización introduce un problema diferente a la pregunta original. Parece que el problema original ya no es un problema. Me refiero a la actualización.

Elmanuallee:

ChrootDirectory
Especifica el nombre de ruta de un directorio chroot(2)después de la autenticación. Al iniciar la sesión, sshd(8)se comprueba que todos los componentes del nombre de ruta sean directorios de propiedad raíz en los que ningún otro usuario o grupo pueda escribir.

Mis pruebas indican que si esta condición no se cumple, se obtendrá Broken pipeal intentar iniciar sesión con sftp.

En su caso, la ruta es /path/to/shared_folder/%u. Nota %u(después de la expansión) estambiénun componente; por lo tanto, debe ser "propiedad de root y ningún otro usuario o grupo puede escribirlo". Debes arreglar la propiedad y los permisos. Entonces, obviamente, el usuario no podrá escribir en el directorio. Cualquiera que sea el nombre de ruta que utilice ChrootDirectory, el usuario no podrá escribir en él (a menos que sea root). En otras palabras, el usuario no podrá escribir /en el entorno chroot. Para permitir la escritura, necesita un subdirectorio. Hay pocas maneras de lidiar con esto.

• Usar directorios de inicio en un directorio chroot común.

  El manual también dice:

  Después de chroot, sshd(8)cambia el directorio de trabajo al directorio de inicio del usuario.

  Supongo que los directorios de inicio son como /home/user1, /home/user2etc. de forma predeterminada. Esto sugiere el siguiente escenario:

  1. Configure el servidor para realizar chroot en /path/to/shared_folder(no %u):

     ChrootDirectory /path/to/shared_folder
     

  2. Replica la estructura de directorio relevante allí ( /path/to/shared_folder/home/user1etc.).

  3. Satisfacer la condición para path, toy shared_folder.
  4. Haga que la propiedad y los permisos sean homesimilares a los habituales /home.
  5. Realice la propiedad y los permisos de los directorios internos homecomo lo son para los directorios en /home.

  Con esta configuración, se colocará sftpautomáticamente después de la autenticación, pero lo verán como debido a .user1/path/to/shared_folder/home/user1/home/user1chroot

• Usar directorios personalizados en un directorio chroot común.

  Con ForceCommand internal-sftppuede especificar el directorio de inicio ( internal-sftpadmite el mismo conjunto de opciones quesftp-server). Como esto:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /home/%u
  

  para asegurarse de que sftplos usuarios lo utilicen /path/to/shared_folder/home/…independientemente de sus directorios de inicio formales en el sistema operativo. O así:

  ChrootDirectory /path/to/shared_folder
  ForceCommand internal-sftp -d /%u
  

  para simplificar caminos y deshacerse de esto homeen el medio. De esta manera user1verán que están dentro /user1después de iniciar sesión con sftp. En este caso shared_folderdebería contener directamente carpetas de usuario (no home).

• Usar al menos un subdirectorio en un directorio chroot específico del usuario.

  Las soluciones anteriores permiten a los usuarios explorar los directorios de los demás. Un usuario podrá acceder a chmodsus archivos ( sftpsoportes chmod) para otorgar o denegar el acceso.

  Usó %ucon ChrootDirectory, por lo que lo más probable es que desee crear directorios chroot separados. En tal caso, haga lo que hizo:

  ChrootDirectory /path/to/shared_folder/%u
  

  y establecer la propiedad y los permisos de cada componente (incluido lo que %use expande) para satisfacer la condición. A menos que se trate de acceso de solo lectura, necesita al menos un subdirectorio en el que el usuario pueda escribir. Pocas posibilidades:

  • replicar la ruta al directorio de inicio del usuario, tal como se define en el sistema operativo;
  • forzando /home/%ucon ForceCommand internal-sftp -d /home/%u;
  • forzando /%ucon ForceCommand internal-sftp -d /%u;
  • utilizando un nombre de subdirectorio fijo, por ejemplo ForceCommand internal-sftp -d /files.

  En cada caso es necesario preparar la estructura de directorios interna /path/to/shared_folder. Por ejemplo, si desea forzar /home/user1for user1, la ruta relevante será:

  /path/to/shared_folder/user1/home/user1
  

  donde path, toy shared_folder(el primero) user1satisfacen la condición, homesimula /homey (el segundo) user1el usuario puede escribirlo.

Son posibles enfoques más flexibles. Por ejemplo, puedes tener un directorio chroot común para user1y user2, pero uno diferente para user3.

El directorio Chroot es común o no, personalmente haría los subdirectorios de la manera menos sorprendente, para que cualquier usuario se encuentre en un directorio que espera. Después de escribir pwddeberían sftpver algo así /home/user1. Encuentro otras posibilidades ( /user1, /files) algo sorprendentes.