If you’re playing with the excellent new ChrootDirectory and internal-sftp options in recent OpenSSH releases (such as 5.1 which is in Ubuntu 8.10 Intrepid), you may have hit an error like:
fatal: bad ownership or modes for chroot directory
You may also have searched on Google for what to do about it and come away with very little useful information.
Well no more! I did the same thing and got bored of reading mailing list posts, so read the source code instead. The relevant section is in session.c:
if (stat(component, &st) != 0)
fatal(“%s: stat(\”%s\”): %s”, __func__,
component, strerror(errno));
if (st.st_uid != 0 || (st.st_mode & 022) != 0)
fatal(“bad ownership or modes for chroot ”
“directory %s\”%s\””,
cp == NULL ? “” : “component “, component);
This is quite simple really, it’s stat()ing the directory specified for “ChrootDirectory” and all its parents up to / and checking that they are:
owned by root
not group or other writable
(it also checks they are actually directories, but I’m going to assume you’re not stupid enough to try and chroot into a file )
Note my emphesis that these checks apply to the chroot directory itself and its parents and /, so if you are chrooting users into /srv/chroot/ then you need to ensure that /, /srv and /srv/chroot are owned by root and not writable by the group (even if it’s root, bizarrely) or other users.
Adopted from : http://www.tenshu.net/archives/2008/10/09/openssh-51-chrootdirectory-permissions-issue/
Wow, thanks a lot! A friend of mine had this Problem with his Synology DiskStation and we’ve been debugging for hours now, until I found your blog post. Group permissions of the parent directory … who’d have thought that?
This solution helped me to resolve the issue.
Thanks,
Now THAT is getting to the root of the issue! Digging into the source code.
Good Job, I’d been bouncing around on the forums and searches too, thanks for providing this info.
Funky thing about this security checking is that it seems to bypass the group perms should I want to have users of a group have r/w access to a directory owned by the group.
Takahisa, congratulations on the insight of having had the idea to open the code and verify that the system was expecting. I’ve been debugging for a few hours and only managed to solve after reading your post. Thank you.
straight to the source!
A
Thank you !
Thanks 🙂
A great post, after a lot of messing about trying to get the user able to login, I found this post and now they finally can!
Unfortunately the remote user is still unable to see any files in the directory!
After 90mins trying various permissions on files and directories & googling I give up! I will post them the file on a USB!
Cheers!
This was such a clear and concise explanation of the ownership and permission requirements for chroot and openssh. It narrowed my focus and helped me sole the problem in minutes. Thanks!
%s/sole/solve/g
Hi,
This is a great bit of work but how does it translate into the commands required to set up a chrooted user directory correctly?
Thanks,
Ian
Thank you for the finding. Your page is hard to find. I only stumbled upon it after someone’s answer kindly quoted their source. Great to see there are people that knows how to go right to the source instead of banging their head on stackoverflow.