So While I've been looking into ways of locking down users and locking them down into jails. I've came across an interesting question that I haven't seen answered anywhere.

How can one posses the power to jail the root account? I'm trying currently with the following: Match user root ChrootDirectory /opt/somedirectory/anotherdirectory ForceCommand internal-sftp But I keep getting disconnected upon connection. - For this use case since its a lab environment I have allowed PasswordAuthentication and PermitRootLogin.

I understand that Chroot jails use the superuser permissions in order to lock people in their own little environments. But is there something can can jail root? Or at least lock him down to a specific directory so he can't cd back? Its an interesting case I'd like to explore and learn more about! Thanks for your time in answering!

TL;DR: How can you sftp jail a root to a specific directory.

  • I am afraid root cannot be "imprisonned" any way. But I would use a virtual machine instead, that is a real unbreakable environement. – schweik Sep 18 at 11:44
  • There's no particular reason that an sshd ChrootDirectory setup should fail for root. If it's not working, the chroot directory may not be set up correctly. Please edit your question to show exactly how the chroot directory and sshd are setup. Run ssh with the "-v" option to print debugging output and include that in your question. And check syslogs on the server to see if sshd is logging any errors about the chroot setup. – Kenster Sep 18 at 13:29

You can't.

Red Hat has an article on this ( linked here ) - if you're looking into using chroots, I recommend reading the whole article. Here is an excerpt from the article that outlines why this won't work:

chroot and the root user

The chroot() system call is only available to the root user. A non-root user cannot execute a chroot() call. This is a good thing because if you are able to call chroot(), you can break out of it. This is not a bug in chroot(), it is just how it works. Even if you wanted to consider this a bug, you have to remember that root generally has access to the system and all resources. Nothing would prevent root from just modifying the process memory directly to change the chroot() location back to '/'. The important thing to consider here is that, by design, chroot() will not stop root. This point will be important later on in this article.

If this is a lab environment as you say, just add a normal user with a simple password (or even SSH keys for passwordless logon)

| improve this answer | |

Turns out everything can be managed properly as long as each directory along the absolute path (for example /var/log/www) has to be readable by root. In SSHD_Config we need to add the following lines:

Subsystem sftp internal-sftp
Match user Root
ChrootDirectory /var/log/www
ForceCommand internal-sftp

This will then forbid root from logging into ssh and only allow him to connect to the sftp system in the given ChrootDirectory (being the jail). Hope this helps someone one day!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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