This has been tested on version 1.003.1.

Note: This is currently a work around, and could result in an unexpected folder structure on S3. Stay tuned for a future update to support this use case.

SFTP Gateway by default creates subfolders for uploads and downloads:

• downloads
• local
• shared
• uploads

However, there are circumstances where the SFTP user needs to write to SFTP root, and these files need to move to S3. For example, there could be 3rd party software (e.g. a call-center appliance) that has limited configuration options.

There is a way to configure SFTP Gateway so that you can write directly to the SFTP root, and have these files forward to S3.

Change the Upload directory

SFTP Gateway uses a config file located here:

/home/ec2-user/.sftpgateway/sftpgateway.properties

By default, the uploaddir is set to uploads. Update it so it looks like this:

sftpgateway.uploaddir=

The next time you run sudo addsftpuser <user>, incrontab will start monitoring /home/<user>/home/<user>

Change the S3 custom path

A blank uploaddir is not something we originally had in mind. So there's a double-slash side-effect with the S3 path:

s3://<bucket-name>/<user>//

To fix this, you can use a custom S3 path:

sudo addsftpuser robtest

Would you like to modify the current S3 location (sftpgateway-i-0653c00849f5d316a/robtest//) for this user? 
[y/N]: y
Please enter the S3 bucket name to use for this user: sftpgateway-i-0653c00849f5d316a
Please enter the S3 path to use for this user: robtest

Now, files dropped into /home/<user>/home/<user> will upload to:

s3://<bucket-name>/<user>/

Note: Even if you don't care about the double-slash in the S3 path, make sure you still run sudo addsftpuser so that the uploaddir setting change applies to that user.

Grant the user write access to SFTP root

By default, SFTP Gateway v1.003 does not allow users to write to SFTP root:

/home/<user>/home/<user>

To fix this, make the user the owner of this folder:

sudo chown robtest:robtest /home/robtest/home/robtest

Note: The SFTP user will no longer be able to connect at this point. So it's important to perform the next step.

Restore the SFTP user's ability to log in

After changing ownership of the SFTP root folder, the user will no longer be able to log in via SFTP. If you look at the log file /var/log/secure, you'll see that the there's bad ownership on the SFTP root folder. This is because SFTP on Linux requires that root own each user's SFTP root.

The trick is to change the ChrootDirectory to %h:

First, edit the following file:

sudo vi /etc/ssh/sshd_config

Second, scroll to the bottom and change this line:

ChrootDirectory /home/%u/home/%u

To:

ChrootDirectory %h

Finally, apply your changes by restarting the sshd service

sudo service sshd restart

SFTP on Linux requires that root own each user's SFTP root. If anyone other than root has write access, the user is denied login.

The trick to get around this is to set SFTP root to %h, or /home/<user>. For some reason, SFTP users still get dropped into /home/<user>/home/<user>. The key is that the true SFTP root, and the directory where the SFTP user lands -- these are two separate locations. This means we can:

• Lock down the true SFTP root /home/<user> to root ownership (SFTP Gateway takes care of this by default)
• Open up permissions on the SFTP user's landing directory /home/<user>/home/<user>, so SFTP users can write to what they "perceive" as their SFTP root

Test the SFTP user's access

At this point, the SFTP user should be able to:

• Connect via SFTP
• Drop a file in the SFTP root directory /home/<user>/home/<user>
• The file should move to S3, and then disappear
• The file should appear in s3://<bucket-name>/<user>/