How to upload files to SFTP root
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>
toroot
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>/