FTP/SFTP访问Amazon S3存储桶

zga*_*ll1 134 ftp sftp amazon-s3

有没有办法使用FTP或SFTP连接到Amazon S3存储桶,而不是AWS控制台中的内置Amazon文件传输接口?奇怪的是,这不是一个现成的选择.

Mar*_*ryl 85

有三种选择.您可以使用Amazon最近添加的本机托管SFTP服务(更容易设置).或者,您可以将存储桶安装到Linux服务器上的文件系统中,并使用SFTP作为服务器上的任何其他文件访问这些文件(这可以提供更好的控制).或者您可以使用本机支持S3协议(免费)的(GUI)客户端.

托管SFTP服务

  • 在您的Amazon AWS Console中,转至AWS Transfer for SFTP并创建新服务器.

  • 在SFTP服务器页面中,添加新的SFTP用户(或多个用户).

    • 用户权限由IAM服务中的关联AWS角色控制(为了快速入门,您可以使用AmazonS3FullAccess策略).

    • 角色必须具有信任关系transfer.amazonaws.com.

有关详细信息,请参阅我的指南设置对Amazon S3的SFTP访问.

将存储桶安装到Linux服务器

只需使用s3fs文件系统(或类似)将存储桶挂载到Linux服务器(例如Amazon EC2),然后使用服务器的内置SFTP服务器访问存储桶.

有关详细信息,请参阅我的指南设置对Amazon S3的SFTP访问.

使用S3客户端

或者使用任何免费的"FTP/SFTP客户端",这也是"S3客户端",并且您没有在服务器端设置任何内容.例如,我的 WinSCPCyber​​duck.

  • @elvismdev /others - 以 ftp 用户身份挂载(使用 uid/gid 选项)并确保使用 `allow_other` 挂载(如果从 s3fs 命令行挂载,则使用 `-oallow_other` 挂载).. 对我有用。在我的例子中(在私有存储桶上),将文件写入只读权限(-o default_acl=public-read)也是一个好主意。 (3认同)
  • 将桶安装为"root"时,在通过SFTP连接"ec2-user"时会出现以后传输"权限被拒绝"的问题.`/ mnt/<bucket>`文件夹由`root`拥有,并且也有'root`组. (2认同)

Mic*_*bot 63

更新

S3现在为S3提供了一个完全托管的SFTP网关服务,它与IAM集成,可以使用aws-cli进行管理.


有理由和实际的理由说明这不是一个完美的解决方案,但确实有效......

您可以在Linux服务器上安装FTP/SFTP服务(如proftpd的),无论是在EC2或您自己的数据中心......然后装入桶到其中的FTP服务器配置为chroot环境,使用文件系统s3fs.

我有一个服务于S3内容的客户端,内容由第三方提供给他们,第三方只支持ftp推送......所以,有些犹豫(由于S3与实际文件系统之间的阻抗不匹配)但缺乏是时候编写一个合适的FTP/S3网关服务器软件包(我现在打算做其中一天),我几个月前为他们提出并部署了这个解决方案,他们没有报告系统有任何问题.

作为奖励,因为proftpd可以将每个用户chroot到他们自己的主目录中并且"假装"(就用户所知)proftpd用户拥有的文件实际上由登录用户拥有,这将每个ftp用户分成存储桶的"子目录",并使其他用户的文件无法访问.


但是,默认配置存在问题.

一旦你开始获得几十或几百个文件,当你拉一个目录列表时问题就会出现,因为ProFTPd会尝试一遍.ftpaccess又一遍地读取文件,并且对于目录中的每个文件,.ftpaccess检查是否允许用户查看它.

您可以在ProFTPd中禁用此行为,但我建议最正确的配置是-o enable_noobj_cache -o stat_cache_expire=30在s3fs中配置其他选项:

-o stat_cache_expire (默认为无效)

为stat缓存中的条目指定过期时间(秒)

如果没有此选项,您将减少对S3的请求,但如果外部进程或s3fs的其他实例也在修改存储桶中的对象,您也无法始终可靠地发现对对象所做的更改.我的系统中的值"30"有点随意选择.

-o enable_noobj_cache (默认为禁用)

为不存在的对象启用缓存条目.当s3fs执行某些命令时,s3fs总是必须检查对象(路径)下是否存在文件(或子目录),因为s3fs已经识别出一个不存在的目录,并且在其自身下面有文件或子目录.它增加了ListBucket请求并使性能变差.您可以为性能指定此选项,s3fs会在stat缓存中记住对象(文件或目录)不存在.

此选项允许s3fs记住.ftpaccess不存在的内容.


与ProFTPd可能出现的性能问题无关,这些问题由上述更改解决,您还需要-o enable_content_md5在s3fs中启用.

-o enable_content_md5 (默认为禁用)

通过content-md5标头验证上传数据而不使用multipart.允许在上传没有多部分发布的对象时发送"Content-MD5"标头.如果启用此选项,则在上载小对象时会对s3fs的性能产生一些影响.因为s3fs在上传大对象时总是检查MD5,所以此选项不会影响大对象.

这是一个永远不应该是一个选项的选项 - 它应该始终启用,因为不这样做会绕过关键的完整性检查,只能获得可忽略的性能优势.当使用Content-MD5:标题将对象上载到S3时,S3将验证校验和,如果对象在传输过程中损坏,则拒绝该对象.尽管不太可能,但禁用此安全检查似乎是短视的.

引用来自s3fs的手册页.语法错误在原始文本中.

  • 你能详细说明这个解决方案不理想的原因吗? (4认同)
  • @MarcoMarsala已将大目录的修复程序添加到答案中. (2认同)

Rya*_*man 22

好吧,S3不是FTP.但是,有很多客户端支持S3.

几乎所有OS X上值得注意的FTP客户端都支持,包括TransmitCyber​​duck.

如果您使用的是Windows,请查看Cyber​​duckCloudBerry.

  • 我认为值得一提的是,如果使用 AWS Transfer 系列,他们可能会产生大量成本。在您的终端上启用 SFTP: 按每小时 0.30 美元的费率计算,您每月的 SFTP 费用为: 0.30 美元 * 24 小时 * 30 天 = 216 美元 SFTP 数据上传和下载: 按 0.04 美元/GB,您通过 SFTP 上传和下载数据的每月费用为: 0.04 美元 * 1 GB * 30 天 = 1.20 美元 加上上述费用,您的 AWS Transfer 系列每月账单总额将为:216 美元 + 1.20 美元 = 217.20 美元。 (4认同)
  • 如果你是像我这样的服务器新手,Cyber​​duck的工作非常简单.只需单击Open Connection,从下拉列表中选择S3,然后输入我的凭据.比上面提到的一些选项容易得多! (2认同)

mit*_*aka 7

或者在AWS基础架构中为SFTP Gateway旋转Linux实例,将上传的文件保存到Amazon S3存储桶.

Thorntech提供支持

  • 多年来,我们一直在大型项目中使用SFTP Gateway.我们发现它比s3fs更可靠 (2认同)