Yolinux.com Tutorial

sFTP Server Chroot Configuration

This sFTP tutorial covers the configuration required to chroot a user to a home directory for sFTP sessions and deny the user a shell account.

Tutorial Table of Contents:

Related YoLinux Tutorials:

°Web Site Configuration

°Internet Security

°Disc Quotas

°YoLinux Tutorials Index




Free Information Technology Magazines and Document Downloads
TradePub link image


Description:

This configuration will allow a system user to access their home directory using sFTP and to upload and download files with their account. The user will be denied access to the rest of the system as they will be chrooted to the user home directory. Thus users will not be able to snoop around the system to /etc or application directories. User login to a shell account will also be denied.

The ability to chroot an sshd session of sftp has been available since OpenSSH 4.9. This is available with Red Hat Enterprise Linux 6 and Fedora 11 (and later) with OpenSSH 5.1. Ubuntu 11.04 uses OpenSSH 5.8.


Installation:

RHEL 6 packages:
  • openssh-5.3p1-81.el6
  • openssh-clients-5.3p1-81.el6
  • openssh-server-5.3p1-81.el6
  • openssh-askpass-5.3p1-81.el6
  • libssh2-1.2.2-7.el6_2.3
Install: rpm -ivh openssh-5.3p1-81.el6...rpm openssh-clients-5.3p1-81.el6...rpm openssh-server-5.3p1-81.el6...rpm ...


Configuration:

This configuration requires:
  1. create a group designated to be chrooted
  2. add users to the group and deny the user shell access
  3. create user home directories
  4. the ssh daemon will be configured to chroot users of a group designated to be chrooted

1) Define a group of which members will be chrooted:

This is a standard Linux group assignment. The group name is user definable.

Define a group: groupadd sftpusers

Groups are defined in the file /etc/group
sftpusers:x:1002:

2) Add users to the group and deny users shell access:

A non-working shell can be assigned to a user to prevent shell access. Linux includes two shells for this purpose:
  • /sbin/nologin
  • /bin/false
User accounts can be modified after creation: usermod -s /bin/false -g sftpusers

The shell can be assigned to a user upon user account creation: useradd -s /bin/false -G sftpusers userid

The user group and shell assignment can be edited in the file /etc/passwd:
From: user1:x:1000:1000:George,,,:/home/user1:/bin/bash
To: user1:x:1000:1002:George,,,:/home/user1:/bin/false

3) Create user home directories:

The typical user home directory is /home/userid
The use of chroot requires a new root which is not "/". In this configuration we will use /home/sftpusers. All user home directories will have their true physical paths added to the rooted path at /home/sftpusers. Thus the true physical paths will be /home/sftpusers/home/userid but will appear to the user to be at /home/userid

The user "root" must own the rooted directory: chown root.root /home/sftpusers

The user "root" should own the rooted home directory: chown root.root /home/sftpusers/home

The user will own their home path: chown userid.sftpusers -R /home/sftpusers/home/userid

Set appropriate permissions: chmod 755 /home/sftpusers/home/userid/

Tip: Set SELinux rules on home directory: setsebool -P ssh_chroot_rw_homedirs on

4) SSH daemon configuration to chroot a user group:

Edit the sshd configuration file: /etc/ssh/sshd_config
(partial file shown)
...
...

#UsePAM no
UsePAM yes
UsePrivilegeSeparation yes
StrictModes yes
PermitEmptyPasswords no

# change default
# Subsystem     sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp

Match Group sftpusers 

ChrootDirectory /home/sftpusers
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

[Potential Pitfall]: You may get the following error:

[user1]$ sftp user1@sftp.megacorp.com
Connecting to 192.121.121.1...
user1@sftp.megacorp.com's password: 
Write failed: Broken pipe
Couldn't read packet: Connection reset by peer
This is typically due to a miss-configuration: Note that sshd will reject sftp connections to accounts that are set to chroot into any directory that has ownership/permissions that sshd doesn't consider secure.

[Potential Pitfall]: You may get the following error:

sftp> put example.sql
Uploading example.sql to /home/user1/example.sql
Couldn't get handle: Permission denied
This is typically due to a directory permissions problem:
/home/sftpusers - owned by root. This will be chrooted.
/home/sftpusers/home - owned by root.
/home/sftpusers/home/user1 - owned by user

After sshd has chrooted to the ChrootDirectory, it will chdir to the home directory as normal.


Chrooting individual users:

Example sshd configuration file: /etc/ssh/sshd_config
(partial file shown)
...
...

#UsePAM no
UsePAM yes
UsePrivilegeSeparation yes
StrictModes yes
PermitEmptyPasswords no

Subsystem       sftp    internal-sftp

Match User userx

ChrootDirectory /home/sftpusers
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Note: This configuration specified a single or comma separated list of users.


Links:

Man pages:


Books:

Amazon book image "Fedora 14 Administration and Security"
by Richard Petersen
Surfing Turtle Press, ISBN# 1936280221
(Jan 6, 2011)

Amazon.com
Amazon book image "Fedora 14 Networking and Servers"
by Richard Petersen
Surfing Turtle Press, ISBN# 1936280191
(Dec 26, 2010)

Amazon.com

   

    Bookmark and Share


Advertisements





Copyright © 2012 by Greg Ippolito