SDB:SFTP server with Chroot
|Tested on openSUSE||Recommended articles||Related articles|
Since OpenSSH 4.8p1 (and therefore available for every openSUSE distribution), the new option ChrootDirectory for /etc/ssh/sshd_config is introduced. This way makes it easy to replace a basic FTP service with SFTP instead without the hassle of configuring encryption and/or bothering with FTP passive and active modes when operating through a NAT router. This is also simpler than using packages such as rsh, scp only or other patches because it does not require setting up and maintaining (i.e. security updates) a chroot environment.
- You understand the basics of openSSH
- You must have an up and running SSHD. If not yet, please refer to Configure openSSH
And you must be familiar with the following basics:
- Working from the command line
- Editing text files
- Gaining root privileges (using su, sudo or login as root)
- Be familiar with Yast2 module: “Users and Groups”
Edit /etc/ssh/sshd_config with your favourite editor as root.
In order to let the ChrootDirectory work, you must use the SSHD internal SFTP server. Locate the following line, comment it out and add the new option:
# override default of no subsystems #Subsystem sftp /usr/lib64/ssh/sftp-server Subsystem sftp internal-sftp
Match rule block
A "Match rule block" can be used to set specific options for certain users or groups. A "Match rule block" always has to be at the bottom of the configuration file. All options set under this line will apply for this block, until a next "Match rule block" is specified. In this example a "Match rule block" is set up for the group "sftponly".
Match group sftponly ForceCommand internal-sftp ChrootDirectory /home/%u X11Forwarding no AllowTcpForwarding no
- The ForceCommand option makes sure that the restricted users can only use the SSHD for SFTP, so they don't have the possibility of opening a regular SSH session. The ForceCommand option must always be the first one! Don't let other examples on the internet misguide you. If the "internal-sftp" is not running before the call to chroot() then the chroot() will fail, since the "internal-sftp" is doing all the dirty jobs to make this possible. If the chroot() fails, the user will be kicked off.
- The ChrootDirectory option sets the new root directory for this user. %u can be used as username replacement and %h can be used for path to home directory. The use of %u is stonger recommended, especially if you are going to create separate users only for SFTP, without local login.
- X11Forwarding and AllowTcpForwarding are both set to no, to prevent the user from forwarding ports or starting remote X applications.
So now the configuration is set so that the restricted user can only login through SFTP, can only access the set directory and cannot use the established connection for anything else. Save the file and exit your editor. Don't forget to reload your SSHD configuration with:
If permissions are not set correctly on the Chroot directory, the operation will fail. This is a safety precaution of the ChrootDirectory command. The directory you Chroot to must be owned by root. The group must be set to your "sftponly" group. Permissions must be set to 750. Meaning:
- Root can read and write
- Members of the sftponly group can only read
- World can not read nor write
- (some guides on the internet say all parents of the chroot up to / also need those permissions. this is not true for us)
A new directory for the Chroot will be created and permissions will be set as above in the following example. As root do:
$chown root:sftponly /sftp/chroot
$chmod 750 /sftp/chroot
$ls -l /sftp
drwxr-x--- 2 root sftponly 4096 2010-07-03 22:09 chroot
If the output of ls -l is similar as above, it means your permissions are OK.
Prepare the users
Now you can simply add the users you want to restrict to the group "sftponly" using Yast2 > Security and Users > User and Group management. If you are creating separate users for the use of your SFTP server, it is also advisable to change there shell to /bin/false. Preventing them from ever logging in to your system. When the call to Chroot has been made and executed correctly, the SSHD will try to change the user's directory to /home/user, relative the Chroot directory. If this folder is not present, the user will remain in the root. If you would like to change this behaviour, you must change the user's home directory to "/". The downside of this is, that public key authentication can not be used any more in the default ways.
You should now be able to login to your computer with a sftponly user and not be able to view your actual computer's root. (Try ls /, this should give you only the contents of your Chroot directory.)
When using pam_google_authenticator.so you can exclude your group in /etc/pam.d/sshd like
auth [success=1 default=ignore] pam_succeed_if.so user ingroup sftponly
befor the google auth pam line