Saltar al contenido

Acceso FTP / SFTP a un bucket de Amazon S3

Solución:

Hay tres opciones.

  • Puede utilizar un servicio SFTP administrado nativo agregado recientemente por Amazon (que es más fácil de configurar).
  • O puede montar el depósito en un sistema de archivos en un servidor Linux y acceder a los archivos usando SFTP como cualquier otro archivo en el servidor (lo que le brinda un mayor control).
  • O simplemente puede usar un cliente (GUI) que admita de forma nativa el protocolo S3 (lo que es gratuito).

Servicio SFTP gestionado

  • En su consola de Amazon AWS, vaya a AWS Transfer for SFTP y cree un nuevo servidor.

  • En la página del servidor SFTP, agregue un nuevo usuario (o usuarios) SFTP.

    • Los permisos de los usuarios se rigen por un rol de AWS asociado en el servicio de IAM (para un inicio rápido, puede usar AmazonS3FullAccess política).

    • El rol debe tener una relación de confianza con transfer.amazonaws.com.

Para obtener más información, consulte mi guía Configuración de un acceso SFTP a Amazon S3.


Montaje del depósito en el servidor Linux

Simplemente monte el cubo usando s3fs sistema de archivos (o similar) a un servidor Linux (por ejemplo, Amazon EC2) y utilice el servidor SFTP integrado del servidor para acceder al depósito.

  • Instala el s3fs
  • Agregue sus credenciales de seguridad en un formulario access-key-id:secret-access-key para /etc/passwd-s3fs
  • Agregue una entrada de montaje de cucharón a fstab:

    <bucket> /mnt/<bucket> fuse.s3fs rw,nosuid,nodev,allow_other 0 0
    

Para obtener más información, consulte mi guía Configuración de un acceso SFTP a Amazon S3.


Usar cliente S3

O usa cualquiera gratis “Cliente FTP / SFTP”, eso también es un “Cliente S3”, y no ha configurado nada en el lado del servidor. Por ejemplo, mi WinSCP o Cyberduck.

WinSCP tiene incluso scripting e interfaz .NET / PowerShell, si necesita automatizar las transferencias.

Actualizar

S3 ahora ofrece un servicio de puerta de enlace SFTP totalmente administrado para S3 que se integra con IAM y se puede administrar mediante aws-cli.


Hay razones teóricas y prácticas por las que esta no es una solución perfecta, pero funciona …

Puede instalar un servicio FTP / SFTP (como proftpd) en un servidor Linux, ya sea en EC2 o en su propio centro de datos … luego montar un depósito en el sistema de archivos donde el servidor ftp está configurado para chroot, usando s3fs.

Tengo un cliente que sirve contenido desde S3, y el contenido se lo proporciona un tercero que solo admite push ftp … así que, con algunas dudas (debido a la falta de coincidencia de impedancia entre S3 y un sistema de archivos real) pero no el momento de escribir un paquete de software de servidor de puerta de enlace FTP / S3 adecuado (que todavía tengo la intención de hacer uno de estos días), propuse e implementé esta solución para ellos hace varios meses y no han informado de ningún problema con el sistema.

Como beneficio adicional, dado que proftpd puede hacer chroot a cada usuario en su propio directorio de inicio y “pretender” (hasta donde el usuario puede saber) que los archivos que pertenecen al usuario de proftpd son en realidad propiedad del usuario que inició sesión, esto segrega a cada usuario de ftp en un “subdirectorio” del depósito y hace que los archivos de otros usuarios sean inaccesibles.


Sin embargo, existe un problema con la configuración predeterminada.

Una vez que comience a obtener algunas decenas o cientos de archivos, el problema se manifestará cuando extraiga una lista de directorio, porque ProFTPd intentará leer el .ftpaccess archivos una y otra vez y otra vez, y para cada archivo en el directorio, .ftpaccess se comprueba para ver si el usuario debe poder verlo.

Puede deshabilitar este comportamiento en ProFTPd, pero sugeriría que la configuración más correcta es configurar opciones adicionales -o enable_noobj_cache -o stat_cache_expire=30 en s3fs:

-o stat_cache_expire (el valor predeterminado es no caduca)

especificar el tiempo de expiración (segundos) para las entradas en el caché de estadísticas

Sin esta opción, realizará menos solicitudes a S3, pero tampoco siempre descubrirá de manera confiable los cambios realizados en los objetos si los procesos externos u otras instancias de s3fs también están modificando los objetos en el depósito. El valor “30” en mi sistema se seleccionó de forma algo arbitraria.

-o enable_noobj_cache (el valor predeterminado es deshabilitado)

habilitar entradas de caché para el objeto que no existe. s3fs siempre tiene que verificar si el archivo (o subdirectorio) existe bajo el objeto (ruta) cuando s3fs hace algún comando, ya que s3fs ha reconocido un directorio que no existe y tiene archivos o subdirectorios debajo de sí mismo. Aumenta la solicitud de ListBucket y hace que el rendimiento sea malo. Puede especificar esta opción para el rendimiento, s3fs memoriza en la caché de estadísticas que el objeto (archivo o directorio) no existe.

Esta opción permite a s3fs recordar que .ftpaccess no estaba allí.


Sin relación con los problemas de rendimiento que pueden surgir con ProFTPd, que se resuelven con los cambios anteriores, también debe habilitar -o enable_content_md5 en s3fs.

-o enable_content_md5 (el valor predeterminado es deshabilitado)

verificar los datos cargados sin multiparte por el encabezado content-md5. Habilite para enviar el encabezado “Content-MD5” al cargar un objeto sin publicación en varias partes. Si esta opción está habilitada, tiene algunas influencias en el rendimiento de s3fs al cargar objetos pequeños. Debido a que s3fs siempre verifica MD5 al cargar un objeto grande, esta opción no afecta al objeto grande.

Esta es una opción que nunca debería haber sido una opción; siempre debería estar habilitada, porque no hacer esto evita una verificación de integridad crítica por solo un beneficio de rendimiento insignificante. Cuando se carga un objeto en S3 con un Content-MD5: encabezado, S3 validará la suma de comprobación y rechazará el objeto si está dañado en tránsito. Por improbable que sea, parece miope desactivar esta comprobación de seguridad.

Las citas son de la página de manual de s3fs. Los errores gramaticales están en el texto original.

Respuesta de 2014 para las personas que me votaron en contra:

Bueno, S3 no es FTP. Sin embargo, hay muchísimos clientes que admiten S3.

Casi todos los clientes FTP notables en OS X tienen soporte, incluidos Transmit y Cyberduck.

Si está en Windows, eche un vistazo a Cyberduck o CloudBerry.

Respuesta actualizada para 2019:

AWS ha lanzado recientemente el servicio AWS Transfer for SFTP, que puede hacer lo que está buscando.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *