4.0 KiB
| title | date | last_modified_at | url | layout | category | image | description |
|---|---|---|---|---|---|---|---|
| Build a secure reception folder for SFTP files transfer | 2019-02-04 | 2022-06-11 11:31 | build-a-secure-reception-folder-for-sftp-files-transfer | post | Security | /img/blog/build-a-secure-reception-folder-for-sftp-files-transfer.png | How to transfer files over SFTP to a server with less privileges as possible ? |
Introduction
Using SFTP from SSH daemon is, in my opinion, not really well-documented and thrown errors are not always very explicit.
Add some security in the mix and nothing works as expected.
This is a short guide (acting a bit as a memo I admit) for SSH + SFTP + Chroot + Public key authentication 😉
The procedure
On "SFTP" server side
Firstly we will create a new unprivileged user, without any password :
{% highlight bash %}
adduser archiver
-s /bin/bash
--home /home/archiver
--disabled-password
{% endhighlight %}
Now that is done, we may start our reception folder creation (still as root) :
{% highlight bash %} mkdir -p /home/archiver/chroot/folder {% endhighlight %}
As clients will put their files into folder/, the system user they will be using must have permissions on it :
{% highlight bash %} chown archiver:archiver /home/archiver/chroot/folder {% endhighlight %}
⚠️ This is important, each one of the path elements leading to the chroot destination folder MUST HAVE 0755 UNIX permissions at most ⚠️
You can enforce this statement with the following (commented lines should be already OK, but who knows ?) :
{% highlight bash %} #chmod 0755 / #chmod 0755 /home #chmod 0755 /home/archiver chmod 0755 /home/archiver/chroot {% endhighlight %}
If you don't,
sshwon't be able to chroot anywhere and your operations will crash with misguiding error in SSH logs.
Now we may tweak SSH configuration (/etc/ssh/sshd_config) :
{% highlight config %}
...
Match User archiver X11Forwarding no AllowTCPForwarding no ChrootDirectory /home/archiver/chroot/ ForceCommand internal-sftp -P read,remove -d folder/ {% endhighlight %}
The -P parameter allows us to restrain the operations that clients will be able to perform (black-list).
With read,remove set, clients won't be able to fetch nor remove any files already present (useful for a write-only backup folder).
Run /usr/lib/openssh/sftp-server -Q requests to check which protocol requests you may provide.
I've tried to use the -p that is on the contrary a protocol requests white-list, but couldn't figure out why it didn't work with the thrown errors...
Please note that those protocol requests HAVE NOTHING TO DO with the (S)FTP commands that could be sent (
put,get,cd, etc.).
The -d parameter will directly set clients into folder/.
This is very useful for interactive FTP operations because it allows clients not to cd somewhere and directly perform their actions.
Finally, we restart the sshd daemon :
{% highlight bash %} systemctl restart ssh.service {% endhighlight %}
On "SFTP" client side
We will begin here by generating a new ED25519 keys pair :
{% highlight bash %} cd ssh-keygen -t ed25519 cat .ssh/id_ed25519.pub
Copy here the displayed public key
{% endhighlight %}
Before continuing, you'll have to paste the public key within
/home/archiver/.ssh/authorized_keysfile on your SFTP server.
Now, you should be allowed to perform your first SFTP operation (🎉) :
{% highlight bash %} sftp -q archiver@YOUR.SFTP.SERVER.IP:/folder/ <<< $'put your_file_to_be_transfered.tar.gz' {% endhighlight %}
The command issued in the snippet above IS AN EXAMPLE. Feel free to adapt it your way.
Conclusion
👋