Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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
share|improve this question

1 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).
share|improve this answer
1  
Thank you for the response, I will try this out as soon as I go into the office tomorrow morning and respond back on this post. –  user3513075 Apr 18 at 3:00
    
I added : Subsystem sftp internal-sftp -f AUTH -l INFO to my ssh config file, but I can't see any logs being logged. Maybe I am looking in the wrong place. When I login with root I can see everything being logged to /var/log/messages, but when I use the user client, I cant see anything. I read the section of your post regarding the dev file required in the chroot directory. Are those files suppose to be owned by root or the jailed user ? –  user3513075 Apr 18 at 14:27
    
See my SF A to how to log w/ SFTP. serverfault.com/questions/73319/sftp-logging-is-there-a-way/…;. In the comments someone left a solution for non RedHat distros. –  slm Apr 18 at 15:28
    
Thank you for the response, I went through the instructions, but the issue I am having is that when I do a mount --bind, the user "client" does not see that file anymore. When I winscp into the server with my user "client" the file is not in the /home/client/dev folder. –  user3513075 Apr 18 at 16:38
    
@user3513075 - can you update your Q w/ the specifics? I'm pretty confident that your issue lies w/ the upper directory permissions not being quite right. Were you able to get the logging working at all? –  slm Apr 18 at 23:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.