CHROOT: Unable to copy files to jailed users directory from local machine using WINSCP

Question

I've setup a chroot environment for one of my users called client on my system. I'm using WINSCP to connect to my server from my machine using public key authentication. Everything works fine, I can login, see the home directory (jail directory) and cannot navigate upwards.

The issue I am having at the moment is that I cannot copy files to the server from my local machine. When I do that I am getting Permission denied : Cannot create remote file /home/client/test.txt

My server is a Red Hat server and this is my sshd configuration:

    Match User client
    ChrootDirectory %h
    PubkeyAuthentication yes
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

I've looked online for this and I've found some notes regarding making copies of the bin and lib folder on the client's home directory, but those solutions didn't help.

All I need at the moment is for the user to be able to copy files from their local machine to my server under their chroot folder.

EDIT #1

Here is a quick description of what I have done:

I have a chrooted user (username: clientd) which I've jailed inside their home directory. This chroot directory is /home/client/ which is owned by root.

Now I need this client user to be able access the tomcat web application folder which is residing under /mnt/datadrive/tomcat/webapps.

What I've done is:

1. chroot the user with a public key of their own to the home directory.
2. Create a folder under /home/client called tomcat_ROOT and given the ownership to clientdev.

Now when I run the command:

$ mount --bind /mnt/datadrive/tomcat/webapps /home/client/tomcat_ROOT

The folder disappears from the directory listing inside /home/client if I login with client. My root user can see it but not the desired user.

Here are some permission listings:

Output of ls -l /home/client/tomcat_ROOT:

drwxr-xr-x.  6 root   root    4096 Apr 11 15:07 .   
drwxrwxr-x. 12 root   root    4096 Apr 11 15:07 .. 
drwxr-xr-x.  3 root   root    4096 Apr  9 22:10 webapp1 
drwxr-xr-x.  4 root   root    4096 Mar 18 18:43 webapp2 
drwxr-xr-x.  3 root   root    4096 Apr  9 22:11 webapp3 
drwxrwxr-x. 10 root   root    4096 Apr 11 15:20 ROOT

Output of ls -l /home/client/:

drwx------. 4 clientdev clientdev 4096 Apr 10 21:36 . 
drwxr-xr-x. 7 root      root      4096 Apr 10 22:07 .. 
-rw-------. 1 client client  664 Apr 10 21:43 .bash_history 
-rw-r--r--. 1 client client   18 Apr 23  2012 .bash_logout 
-rw-r--r--. 1 client client  176 Apr 23  2012 .bash_profile 
-rw-r--r--. 1 client client  124 Apr 23  2012 .bashrc 
drwx------. 2 client client 4096 Apr 10 19:20 .ssh
drwxr-xr-x. 2 client client 4096 Apr 10 21:34 tomcat_ROOT

Answer 1

I have something similar setup and it works so you're configuration looks valid to me. I would suggest adding this line above the Match rule which will enable a bit more verbose messaging in your logs which might help you narrow focus on what the underlying issue is.

Subsystem   sftp    internal-sftp -f AUTH -l INFO

Be sure to restart sshd after the change. I believe your issue has to do with the permissions of either the directory or the user's folder. When using ChrootDirectory there are some very specific conditions you have to be sure to adhere to, otherwise SSHD won't cooperate.

 ChrootDirectory
        Specifies the pathname of a directory to chroot(2) to after 
        authentication.  All components of the pathname must be root-owned 
        directories that are not writable by any other user or group.  
        After the chroot, sshd(8) changes the working directory to the 
        user's home directory.

        The pathname may contain the following tokens that are expanded at 
        runtime once the connecting user has been authenticated: %% is 
        replaced by a literal '%', %h is replaced by the home directory of 
        the user being authenticated, and %u is replaced by the username of 
        that user.

        The ChrootDirectory must contain the necessary files and directories 
        to support the user's session.  For an interactive session this 
        requires at least a shell, typically sh(1), and basic /dev nodes 
        such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) 
        and tty(4) devices.  For file transfer sessions using “sftp”, no 
        additional configuration of the environment is necessary if the in-
        process sftp server is used, though sessions which use logging do 
        require /dev/log inside the chroot directory (see sftp-server(8) for 
        details).

        The default is not to chroot(2).

Answer 2

Can you please check the directory permissions.

like if we have folder structure /home/test/app

than /home/test must have - 'chmod 700' and 'chown testuser test' and /home/test/app must have - 'chmod 750' and 'chown testuser app -R'

Please try

chmod 700 /home/client/
chown clientd /home/client/
cd /home/client/
chmod 750 * -R
chown clientd clientdev * -R

Also let me know if the directory permissions change not works.