changing the root directory for sftp users

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Say I have a user with SFTP access to /home/user01/.  If they go to /
home/user01/../../home/user02/ they can see the contents of user02's
directory.  What I'd like to do is to make it so they can't traverse
up from /home/user01/ - so that, when they logon, via SFTP, /home/
user01/ appears to them as /.

Any ideas as to how this might be done?

Re: changing the root directory for sftp users

On Lun 17 jan 2011, 08:34,

Quoted text here. Click to load it

This can be done in two ways.
With the internal-sftp or the external-sftp subsystems.
If you go with the external-sftp, you'll have to populate a proper
chroot jail for your system (having a login shell, /dev, some /bin
binaries, etc.).

With the internal-sftp subsystem it's far easier as this is an
in-process and requires no more than a regular ssh connection.

Basically this is done by turning on the internal-sftp subsystem in
/etc/sshd_config and deactivating the external subsystem:

# override default of no subsystems
#Subsystem    sftp    /usr/libexec/sftp-server
Subsystem    sftp    internal-sftp

Then make a Match block in /etc/sshd_config to chroot a valid user that
is allowed to connect through ssh:

Match User <user_to_chroot>
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /path/to/chroot

Don't forget that all components of the chroot path MUST be root owned
and NOT writable by any other user or group otherwise the connection

Also you can read the "ChrootDirectory" and "Subsystem"
chapters in sshd_config(5) that briefly describe how things


B.A.R. en sauce feat. L'Omelette - Degiheugi (Only after the show)

Re: changing the root directory for sftp users

Quoted text here. Click to load it

Don't bother. SFTP is useful, but its chroot behavior is very painful
to work with. It's *REALLY* OpenSSH has never worked well for
providing restricted directory access for individual users,
effectively chroot cages. (I used to publish patches for the this,
years back: they were never accepted.)

SFTP for anything other than casueal file transfer access has other
issues. The APO for time display is really not thorougly specced out,
so regional settings in clients and servers can cause significant
confusion. (I ran headlong into this last year.)

For restricted file access, consider FTPS or WebDAV over HTTPS. I've
had very good success with WebDAV over HTTPS, which is built right
into many web clients, including lftp for Linux users, and Network
Neighborhood for Windows users.

Re: changing the root directory for sftp users

On 18/01/2011 00:18, Nico Kadel-Garcia wrote:
Quoted text here. Click to load it

Not all built-in Windows WebDAV clients support DAV over SSL. There's at
least half-a-dozen different clients, each with its own quirks and
defects, including clients provided by various versions of Office and

It's therefore not a bad idea (if you can) to select a 3rd-party WebDAV
client, and ask users to install that, instead of trying to support the
plethora of MS clients, with all their inconsistencies and bugs.


Re: changing the root directory for sftp users

Quoted text here. Click to load it

Oh, I agree that supporting a plethora of tools is not ideal, and many
have been very poor about supporting full feature sets such as SSL for
WebDAV access. But it's built right into the desktop utility, the
"Network Neighborhood". Why use a third-party app of any sort when
it's built right into the operating system for Windows users?
Admittedly, I've not explored it on Windows 7 yet. (Been busy.) But I
suspect there's a similar built-in there.

I've even recently been dealing, from the outside, with merged SFTP/
FTPS/FTP/CIFS/NTFS permissions based access issues. It's a *nightmare*
to resolve these: each tool has their own vagaries, and educating
people that just because one is available doesn't mean the other is
*off* or won't be messed up by someone who doesn't realize that only
one is supported is an.... adventure. Timezones set for FTP access,
for example, cause real adventures for SFTP clients browsing the
repository. The files are *transferred* with the right time stamps,
but if you're loking for SFTP accessible files that are from the last
hour and suddenly see files that are allegedly from the future, it can
be very confusing when you browse the repositorory.

Lesson to be learned? Pick *one* broadly available transfer method,
and use it consistently.

Site Timeline