Issue with CHROOT in sshd_config

Mike Z

Mike Z

Hello everyone,

I'm running a server that I want to lock user access to a directory I created (and mounted a file system to) so that a user cannot browse through my whole system when ssh-ed into my server. I want to use chroot(8) to lock them down to directory /root/storage, which has other sub-directories within it. After adding the chroot(8) configuration to sshd_config I get the following message when attempting to log into the server:

Code: 
fatal: bad ownership or modes for chroot directory component "/root/storage"

My client will also display an authentication error when that message displays on my server. I figured this all might be caused by a permissions issue so I tried to chmod 777 that directory, but it made no difference. Something to note...I have a raid 1 volume mounted to that directory (/root/storage). Could there be any issue due to this? Any other thoughts or insights would be appreciated.

Thanks!! :D
 
Last edited by a moderator:
The root of the chroot, in this case /root/storage, has to be owned by and be writable by root only. (The directories underneath it can be owned and be writable by others).

Personally I would have also mounted storage somewhere else than underneath /root; that directory and everything underneath it should really only ever be accessible by root.
 
Thanks for the information, Nulani. I'll trying mounting it somewhere else, like maybe somewhere in the user's directory and see if I have any better luck.
 
SirDice said:
I really wished people stopped doing this. This is NEVER a solution, so just don't do it ok?
Click to expand...

It might be going about the troubleshooting incorrectly. I don't have a whole lot of experience or knowledge of unix operating systems, and I undertook this project as a personal learning experience (its a personal server not in an enterprise environment or anything). I understand that 777 permissions are essentially opening the directory wide open, but beyond that is there another reason I should not be doing this? Thanks!
 
Mike Z said:
I understand that 777 permissions are essentially opening the directory wide open, but beyond that is there another reason I should not be doing this?
Click to expand...
Not just essentially, you are opening it to the wide world. In general there are only two directories that have permissions like that, /tmp/ and /var/tmp/. And even those have some additional safeguards. It usually boils down to this: if it needs to be world-writable you're probably doing something wrong. Most of the time things aren't working because of other reasons.
 
Understood. I'll keep that in mind when I'm troubleshooting future issues. Thanks for the insight!
 
Unfortunately, I changed the mount point from /root/storage to /mnt/storage and I still get the same message:

Code: 
fatal: bad ownership or modes for chroot directory component "/mnt/storage"
Interestingly, when I change the chroot directory to just /mnt my client will authenticate and then immediately terminate the session. I've verified this with my mobile client as well. Ultimately, I want my user account to only be able to see /mnt/storage directory and all of its sub-directories. If it matters for troubleshooting, I have a raid 1 mirror mounted to /mnt/storage. My guess is it has something to do with ownership of the mirror versus ownership of the directory, but I'm honestly guessing. Any advice would be great. Thanks!
 
Make sure the /mnt/storage directory is owned by the user and has, at the most, 755 permissions.
 
The root of the chroot has to be owned by root and not be writable by any other user or group. Correct permissions on /mnt/storage would be

Code: 
drwxr-xr-x   8 root         wheel
 
So I've changed the owner of the directory to be root, and I was able to verify that using ls -l. Additionally, I was able to verify that the permissions on the directory match Nulani's example (actually I had to change them to match the example, but they now match). Everything seems to be in line with suggestions, but when I set the chroot directory in either the global chroot for ssh or the "match user" section it still behaves the same way. My client application will go through the steps to authenticate (show my banner msg, ask for the password on my keyshare, and list the remaining authentication steps), but the client never actually authenticates. Worst still, it doesn't give me an error message like before, it just exits the client right away after going through all of the steps.
 
Okay I got it to work. Apparently it had to do with the Force Command Internal-SFTP command in the "Match User" section of sshd_config. From what I understand of this command, if a user account is not part of any particular group, you give it the permissions of the internal-SFTP group. Can someone confirm that I understand this correctly?

And also, thanks so much for all of your suggestions and insight! This community is always very helpful to noobs like me :D
 
You must log in or register to reply here.
Back
Top