SFTP is a secure alternative to FTP. Authentication is done via SSH and a secure tunnel is established for the entire file transfer session. In this article I look at how to restrict a user’s access to SFTP only and to a specific directory on the server.
The first step is to add a new user to the system:
adduser sftptest |
Then we change the shell program to /bin/false:
chsh -s /bin/false sftptest |
This will prevent the user from being able to execute arbitrary commands on the server.
Next lets add a group for all users that are restricted to SFTP access only:
addgroup sftpusers |
And add sftptest to sftpusers:
gpasswd -a sftptest sftpusers |
Next append this block in /etc/ssh/sshd_config
Match Group sftpusers
ChrootDirectory /home
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no |
This will restrict all users of sftpusers group to the chroot directory /home. Ideally we would restrict them to their own directories within /home but unfortunately the OpenSSH version included with Debian Wheezy requires that the chroot directory be owned by root.
When they connect to the server the command internal-sftp is run. This means that only SFTP access is available. In some guides a -d switch is used to automatically change the directory to the connecting user’s home directory. In my testing this doesn’t work on Wheezy.
To prevent users from accessing other users’ home directories you should chmod them all to 700:
chmod 700 /home/user1 chmod 700 /home/user2 ... chmod 700 /home/userN |
/home can also be chmodded to 111 to prevent users listing its contents and seeing what other users are on the system:
chmod 111 /home/ |
It is also recommended that you setup public key authentication for each user and avoid using passwords. How to do this is covered in another article.
With the above setup users can securely upload and download files from the server over an encrypted SFTP connection. They are chrooted to /home and file system permissions are used to restrict their access to their own home directory.
But… if i chmod 111 /home/, when i access using SFTP (with Filezilla) i can’t list my own user directory and i can’t access it. Correct me if i´m worng :S
It worked when I last tried it. If it doesn’t work for you then don’t set the /home directory to 111. Leave it to default permissions. Users will be able to see what other users are on the same system but they will not be able to enter other users’ home directories (provided you followed the step of chmodding home directories to 700).
But… if you chmod all the /home directories to 0700, Apache won’t be able to access them, so you will need to have their websites somewhere other than in a subdirectory of their home directories.
See also: every other server.
chmod to 750 to allow group access and add apache to users’ groups. Each user should have its own group like you see in debian based distros.
Or chown the directories user:www-data.
Or create a separate directory /home/htdocs and put each user’s web files in a separate sub-directory underneath that. Only the user will have permission to read and write to his sub-directory and apache will have read and execute permission. Create a symlink to it in the user’s home directory for easy access.
If in sshd_config you use:
ChrootDirectory %h
The users will be sent to their respective home directories when connecting via SFTP instead of to the main home directory.
I can’t seem to figure it out why, not even arch linux’s article helps. https://wiki.archlinux.org/index.php/SFTP_chroot. Rsyncing from a remote server to the backup server’s chrooted account’s home folder gives rsync errors.
I’ve tried to login to the backup’s server’s chrooted user account via ssh backupuser@backupserver, but the ssh connection authenticates and closes immediately saying chdir to backupuser’s home directory: permission denied and /bin/false also gives permission denied errors and then the connection closes.
I’ve realised what my problems were. Rsync doesn’t work with a chrooted account, at least for me, no matter what I’ve tried, but sftp remoteuser@remotehost does.