¿Cómo agregar usuarios con acceso SFTP / FTP a la carpeta '/ var / www / html / website_abc' en Amazon EC2 Centos?


19

Posible duplicado:
permisos de directorio de Linux

Estoy trabajando con algunos desarrolladores externos y me gustaría otorgar acceso SFTP (o FTP) a la carpeta raíz de un sitio web en el que están trabajando, es decir, '/var/www/html/website_abc'para que puedan cargar los archivos allí. Tenga en cuenta que estoy alojando mis otros sitios web allí en la misma instancia EC2, por ejemplo '/var/www/html/website_xyz'.

Solo para enfatizar que estoy trabajando con varios sitios web en una sola instancia de EC2, la estructura de los sitios web es la siguiente:

/ var / www / html /
/ var / www / html / website_abc
...
/ var / www / html / website_xyz

Mis objetivos son los siguientes:

  • El usuario 'adeveloper' tiene acceso a '/ var / www / html / website_abc' y solo '/ var / www / html / website_abc'
    • Supongo que el usuario 'adeveloper' usará 'adeveloper @ [mi IP elástica]' como nombre de usuario para iniciar sesión en SFTP (o FTP), ¿estoy en lo cierto?
  • El usuario 'adeveloper' no tiene acceso a '/ var / www / html /' ni a ningún otro directorio en mi instancia EC2
  • ¿Qué tal el archivo de clave privada?
    • ¿Debo pasar mi archivo de clave privada a los desarrolladores externos? ¿Es recomendable hacerlo?
    • ¿Hay alguna forma de generar un archivo de clave privada diferente para ellos o permitirles iniciar sesión con nombre de usuario y contraseña?

He realizado búsquedas, pero la mayoría de la gente hablaba sobre cómo acceder a EC2 a través de SFTP, que ya puedo usar WinSCP.

Aclaraciones:

  • Necesitaría 'un desarrollador' para poder subir cosas a las /var/www/html/website_abccuales es permiso de 'escritura'
  • Necesitaría 'un desarrollador' para no tener permiso de 'escritura' para ningún archivo / directorio /var/www/html/, e idealmente ni siquiera permiso de 'lectura'
  • Sin embargo, parece haber un gran problema aquí:
    • /var/www/html/ya tiene permiso 777 ya que esta es mi carpeta DocumentRoot. Entonces, ¿cómo evito que 'adeveloper' acceda a mi otro sitio web?

Parcialmente resuelto , logré mis objetivos usando OpenSSH (creo la carpeta .ssh dentro de / var / www / html / website_abc / y genero una clave privada y se la doy a los desarrolladores externos). También aprendí que nunca debería dar el archivo de clave privada que me dio AWS. Todavía estoy aprendiendo sobre chroot.


1
Lo siento @lain pero debes haberme entendido mal. Supongo que podrías pasar tiempo haciendo algo más significativo que dar un falso juicio como este. Quizás si lees mi pregunta cuidadosamente, realmente tendría más que ver con SSH / SFTP que con los permisos de archivos / carpetas de Linux o más bien fue una confusión entre ellos (¿por qué estaba confundido? No sé, es por eso Necesitaba ayuda) Este no es un duplicado exacto del otro hilo como lo consideró. De todos modos, logré alcanzar mis objetivos usando OpenSSH. Todavía estoy aprendiendo sobre chroot como lo sugiere Tom H y algunos resultados de búsqueda. Gracias
ericn

"También aprendí que nunca debería dar el archivo de clave privada que AWS me dio" Por qué .....
Michael Bailey

Respuestas:


11

Por defecto, los servicios que proporcionan un shell remoto, como ssh o telnet, o una sesión remota interactiva para comandos como sftp, permiten que un usuario local cambie a cualquier directorio para el que tenga permisos y recupere una copia de cualquier archivo al que tenga acceso.

Como configuración de seguridad general, esto es desafortunado porque hay muchos archivos y directorios que son legibles por necesidad. Por ejemplo, aquí soy yo un usuario no root en alguna caja remota de CentOS;

$ cd /etc
-bash-3.2$ ls -1
acpi
adjtime
aliases
...

por ejemplo, puedo acceder a muchas cosas, que idealmente querrías restringir a algún usuario desconocido a quien deseas proporcionar acceso local.

Aquí estoy mirando a todos los usuarios locales configurados en el /etc/passwdarchivo;

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...

Los sistemas Unix proporcionan el chrootcomando que le permite restablecer el /usuario a algún directorio en la jerarquía del sistema de archivos, donde no pueden acceder a archivos y directorios "superiores".

Sin embargo, en su caso, sería apropiado proporcionar un chroot virtual implementado por el servicio de shell remoto. sftp se puede configurar fácilmente para restringir a un usuario local a un subconjunto específico del sistema de archivos mediante una configuración en

por lo tanto, en su caso, desea que chrootel adeveloperusuario ingrese al /var/www/html/website_abcdirectorio.

Puede establecer un directorio chroot para que su usuario los confine al subdirectorio de esta /var/www/html/website_abcmanera /etc/ssh/sshd_config;

Esto requiere un servidor openssh posterior a 4.8 ?, entonces probablemente requiera CentOS 6.2

Match Group sftp
    ChrootDirectory %h
    AllowTcpForwarding no

(no probado, ver man sshd_configpara confirmar la sintaxis)

y luego agregue esos usuarios al grupo sftp;

 groupadd sftp
 usermod -d /var/www/html/website_abc adeveloper
 usermod -G sftp adeveloper

En cuanto a claves compartidas

debe crear un par de claves adicional para los usuarios expertos y enviarlo a su asesor. (o, alternativamente, pídales que le envíen su clave pública y la agreguen al archivo autorizado_claves para adeveloper)

nunca renuncies a tu clave privada, por eso se llama privada ;-)

alternativas de ftp tradicionales

vsftp / proftp, etc. también admiten configuraciones chroot, pero en la actualidad las configuraciones basadas en ssh son la forma normal, y el soporte para ftp es solo histórico.

hay un par de enlaces a tutoriales aquí;
http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229

http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny


No he sido capaz de descubrir chroot hasta ahora, pero todavía estoy aprendiendo y todavía no me he rendido. Sin embargo, logré alcanzar mis objetivos establecidos anteriormente con OpenSSH. Gracias de nuevo
ericn
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.