Secure FTP (Secure Shell (ssh) FTP)

A couple of years ago, I had a struggle configuring a secure FTP server. It involved installing restricted shells (rssh), creating that shells own directory system, and making copies of library DLLs because the rssh could not see outside its own directory system. It worked in the end, but I was dismayed at the time – whoever wrote the rssh, no longer supported it.  As far as I could see, the way forward was not using supported software. I was making my system secure, but opening it up to future problems.

Using the secure shell is easier than the standard offering of FTP as it uses a single TCP port (22). I always have firewall problems with standard FTP with its passive and active modes, and choosing random ports for its control communicationFor extra security with my secure shell, I like to use a non-standard port  – 38573 for example. This can be achieved either by changing the entry in sshd_config to Port 38573 or setting up a port redirect on your firewall if you are using NAT. eg  Port 38573 -> 192.168.1.53:22

Anyway, back to SFTP, which I discovered that since version 4.8p1 makes it much easier to use secure FTP. What I am about to describe worked on my Debian OpenSSH_5.1p1.  To find the version type sshd -v (it says illegal option but at least it gives a version number)

Edit the sshd_config file again which you will probably find in /etc/ssh

Find the Subsystem line, which will probably say

Subsystem sftp /usr/lib/openssh/sftp-server

That as my original, if it says anything else you are on your own!

Change this to access the built in system

Subsystem sftp internal-sftp

Add the following to the bottom of the file

Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

The match group makes this section only apply to those user in the sftponly group which we will create in a minute.

ChrootDirectory is the new command keeping the user inside their own directory. The %u translates to the login name, so each user is trapped under their own root directory such as /home/username.

I am not too sure what the forwarding options do apart from stopping forwarding. I will leave it up to the reader to decide if there are implications if you do need it enabled.

ForceCommand internal-sftp forces that user to use ftp, and not allow normal ssh access.

That is it for the configuration. Save the config file, and restart ssh – normally /etc/init.d/ssh restart

Now we are ready to set up the users.

First we create a group (once only)

addgroup sftponly


Now for every new user we want to give sftp access we have to do the following. (replace *user* with the users login!)

Create the account
adduser *user*

root has to own the chroot directory
chown root.root /home/*user*

create a home directory for the user under the chroot
mkdir /home/*user*/home

Give the user ownership of their home
chown *user*.sftponly /home/*user*/home

Change the users home directory to /home
usermod -d /home *user*

Add the user to the sftponly group
adduser *user* sftponly

And thats all there is to it.

One thing to note, the user will log onto the directory /home/*user*/home, and from this level they will be able to upload, download, create and delete, unless you stop them with directory permissions. They will be able to go back up to the chroot directory, /home/*user* At this level, because it is owned by root, they cannot do anything, and the directory is unique to them so it is not a problem.

This is a link to my main source for this adventure.  OpenSSH

previous entry
next entry

Comment (1)

  1. Hi, yeah this post is actually fastidious and I have learned lot of things from it on the
    topic of blogging. thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.