I recently had a request to setup SFTP for a customer so they could manage a set of files in their environment through an FTP GUI. Being an avid user of command line tools like SCP I haven’t needed to set up FTP or SFTP in many years. So I dusted off some guides and fired it up.

While setting everything up it seems as though many guides were missing a critical step in some form or fashion. So I have taken it upon myself to write a guide to detail my entire process from start to finish.

Step 1 – Create a New User

Personally once I am logged into my server I switch to the root user:

$ sudo -s

Let us add a new user

$ adduser [your username]

You will be prompted to add a password. For testing purposes I usually make the password something simple to start and go back and change it to be something secure later on. All other user information is optional so you can simply hit ENTER to move through it if you would like.

 

Step 2 – Creating a Directory to Put Files In

We do not want our new SFTP user to have access to our whole file system as this would be a huge security flaw. So in this guide we are going to restrict the user down to a single directory to add and remove files from.

This is where I found my first hang up. When using SFTP we have to have the directory that the user is going to be forced into owned by root. All directories above that must also be owned by root without any group write permissions. Failing to create this structure properly will result in you not being able to login.

Example Structure:

/var/www/html/ The directory HTML is where our website resides so this is the directory we want to have our SFTP user to be able to write to.

To accomplish this we will actually force our user to the directory /var/www/ this way the WWW and VAR directories can be owned by root while the HTML directory can be owned by www-data which we will then add our new user to.

To accomplish this:

$ chmod 755 /var/www

This changes our permissions to only allow writing by the user who owns the directory while read and execute to everyone else.

$ chown root:root /var/www

This changes our directory to be owned by the user root and group root which satisfies our directory structure requirements.

$ chown -R www-data:www-data /var/www/html/

This gives ownership to the user www-data and group www-data which is the standard Apache user.

Step 3 – Locking Down our User

$ nano /etc/ssh/sshd_config

Note: You can use whatever text editor you like here to edit the file.

Find the section Subsystem sftp /var/lib/openssh/sftp-server Comment it out so it looks like #Subsystem sftp /var/lib/openssh/sftp-server

Add the line Subsystem sftp internal-sftp right below it.

Add the following lines to the very bottom of the file:


Match User [Your New Username] ChrootDirectory /var/www
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
ForceCommand internal-sftp
PasswordAuthentication yes


Save the file and exit.

Match User: Tells the SSH server to only apply the following settings to the one user
ChrootDirectory: This tells the server what directory our user is allowed to ONLY work within this directory
X11Forwading, AllowTCPForwarding, AllowAgentForwarding: Prohibits the user from port forwarding, tunneling and X11 forwarding fot the user. These are all security things.
ForceCommand internal-sftp: Forces the SSH server to the run the SFTP program upon access which disables shell access.
PasswordAuthentication: Allows for the user to login with a typed password. You can remove this is you would rather use a security key which is by far safer.

Restart the SSH Server

$ /etc/init.d/ssh restart

With the SSH server restarted your SFTP user should be able to login and view files. It won’t be able to modify any files yet as we did not give the user access to do so.

$ usermod -a -G www-data [Your User]
This adds the user that you specify to the www-data group. Completing this will allow your user to be able to modify files within the directory /var/www/html

This guide showed you how to create a new user and limit that user to SFTP access only. We also limited that user to our website directory and prevented it from access any other critical system files.

There are so many other complex SSH server configurations. This setup allows for a very specific use case which many people have implemented. While SFTP is secure allowing access to any remote server allows for the possibility of attack. This guide should only be used if you understand the security risks involved with allowing SFTP.

If this guide has been helpful for you and your team please share it with others!