This question is actually too broad...

What I really want to know is whether or not it actually chroots and, if so, how a SSH user deamon[1] can be launched in that jail in spite of the obvious lack of the required binary/lib in the chroot.

Google is surprisingly silent on the matter. But a good reference to explain that woud be enough (however I'm not litterate enough to read and understand their C).

[1]: I'm talking about the actual transient daemon with user priviledges that is launched upon connection by the main root OpenSSH daemon.

2 Answers 2


The other answer is quite vague (also the question is) so I will try to be more verbose about this phenomen. I know that this topic is not for everybody, but for these interested it is quite nice thing to know about.

There are two different places where the chroot is done and you are poking into both of them so I will try to align your ideas:

  1. There is privilege separation, which is security mechanism and part of it is also chroot as a limitation of network child. This is usually some empty directory, like /var/empty.

    The reason is in few words, that if there was some vulnerability, it would be probably not exploitable, because this process doesn't see filesystem and is also limited in other ways (sandbox, SECCOMP keywords for further readings).

  2. Later on you can chroot the user's session (not only SFTP) in specific directory to prevent access to whole filesystem. This is probably the part you are interested, based on the title.

    The magic about sftp in chroot is that you can specify Subsystem sftp internal-sftp (instead of the full path Subsystem sftp /usr/lib/openssh/sftp-server). This implies that sshd has whole sftp-server compiled-in and instead of exec on the binary, it just calls function where the server behaviour is defined. This doesn't require any supporting files in chroot for user (unlike the normal session, where you need shell and its dependent shared objects). You may also require logging socket, if you are interested in such informations.

  • Interesting indeed. I am trying to understand a bit more of the logging socket, what can you tell more about it? Commented Nov 21, 2015 at 14:02
  • I was answering similar question somewhere, but it take me some time to search for it. It was security.stackexchange
    – Jakuje
    Commented Nov 21, 2015 at 14:14
  • Great! This is exactly what I needed. The whole thing os a lot clearer now. Thank you.
    – LouisTP
    Commented Nov 21, 2015 at 21:05
  • And to be more precise, I was originally curious about your point 2. But I am now curious about both :) Program security is a very interesting topic.
    – LouisTP
    Commented Nov 21, 2015 at 21:20

I have been trying to deal with the privilege separation mode of operation, to append some extra logging to ssh called with commands for the remote server. As you say, you do not find much stuff about it.

The obvious key is the option "UsePrivilegeSeparation".

In the process of user authentication, a sshd fork drops the privileges and runs in a chroot using the user sshd. Analysing the source code, I found it chroots to /var/empty.

It also has some checks in place that some operations have to match between the code before and after the chroot, that I have not explored yet.

I will leave also a relevant link:


  • Anyway, thanks for this link. I haven't see it yet. It is great overview of openssh (though not much recent).
    – Jakuje
    Commented Nov 21, 2015 at 20:22
  • Yes, that's definitely some great material. Finally some higher level explanations! Thank you.
    – LouisTP
    Commented Nov 21, 2015 at 21:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .