Jan Pechanec's weblog

I resynced the ChrootDirectory option from OpenSSH to SunSSH, and pushed the change to the repository today. It wasn't a straightforward resync since we have different privilege separation code. I also found a few very minor issues in the OpenSSH code, and filed bugs with patches (1562, 1564, and 1566).

If you want to use the option, create an empty root-owned directory with proper permissions (no group/other writable along the whole path, so don't even use /tmp, for example, since we don't accept the sticky bit). After that, set ChrootDirectory option to it, and check that the Subsystem option contains internal-sftp. This internal SFTP will be the default in the new OpenSolaris/Nevada installations but we do not change any existing confirations on upgrades. It's quite probable you will have an existing config file with the following line:

Subsystem       sftp    /usr/lib/ssh/sftp-server

If you run the server in the debug mode (/usr/lib/ssh/sshd -p 2222 -ddd) with the chroot directory option set and the line as displayed above, you would see something like this in the server's output after you try to connect (sftp -o Port=2222 the-hostname):

subsystem request for sftp
subsystem: cannot stat /usr/lib/ssh/sftp-server under
    chroot directory /var/root/chroot/: No such file
    or directory
subsystem: please see the Subsystem option in
    sshd_config(4) for an explanation of 'internal-sftp'.
subsystem request for sftp failed, subsystem not found

Just change /usr/lib/ssh/sftp-server to internal-sftp, restart the SSH server (svcadm restart ssh), and you will be fine. The chroot directory option does work with the plain SSH connection or with the /usr/lib/ssh/sftp-server binary as well. However, you must provide some files in that directory, because SSH server will exec(2)'s the shell or the SFTP server process after calling chroot(2). My test chroot directory has the same list of files but check that the connecting user has the same shell, bash, as mine. If not, the list of libraries will probably be different, use ldd(1) to get your list. The list follows:

./bin/bash
./bin/ls
./lib/libcurses.so.1
./lib/libsocket.so.1
./lib/libnsl.so.1
./lib/libdl.so.1
./lib/libc.so.1
./lib/libmp.so.2
./lib/libmd.so.1
./lib/libscf.so.1
./lib/libuutil.so.1
./lib/libgen.so.1
./lib/libm.so.2
./lib/libresolv.so.2
./lib/libcrypto.so.0.9.8
./lib/libz.so.1
./lib/libsecdb.so.1
./lib/libmapmalloc.so.1
./lib/libcrypt.so.1
./lib/libsec.so.1
./usr/lib/ld.so.1

and I can log in via plain SSH, and run ls(1) command:

-bash-3.2$ ls
bin  lib  usr
-bash-3.2$ pwd
/

Note that the external SFTP server process would need yet another list of files, and at least one device - /dev/null, but there is really no reason to use the external binary when there is the above mentioned internal-sftp mode. Nothing is exec()'ed, the SFTP server loop is run inside of the existing SSH server process, and that means that no other files are needed in the chroot directory. If you are still not convinced then know that the SFTP server code used is the same. In the in-process implementation, the server uses the SFTP object code that is linked directly to the SSH server binary while in the external case the code is wrapped in an additional few lines to create an independent binary.

The sshd_config(4) manual page will be updated but we are in the queue so I'm not sure it will get to the same Nevada build as the code change, which is 112. It may get to 113. From that reason, see the change here:

+ChrootDirectory
+
+  Specifies a path to chroot(2) to after authentication.
+  This path, and all its components, must be root owned 
+  directories that are not writable by any other user or
+  group.
+
+  The server always tries to change to the user's home
+  directory locally under the chrooted environment but a 
+  failure to do so is not considered an error. In addition
+  to that, the path 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 SSH session this requires at least a user's
+  shell, shared libraries needed by the shell, dynamic
+  linker, and possibly basic /dev nodes such as null(4),
+  zero(4), stdin(4), stdout(4), stderr(4), random(4) and
+  tty(4).  Additionaly, terminal databases are
+  needed for screen oriented applications. For file
+  transfer sessions using ``sftp'' with the SSH protocol
+  version 2, no additional configuration of the
+  environment is necessary if the in-process sftp server
+  is used (see Subsystem for details).
+
+  The default is not to chroot(2).
+
+

      Subsystem

    Configures an external subsystem (for  example,  a  file  
    transfer  daemon).  Arguments should be a subsystem name
    and a command to execute  upon  subsystem  request.  The
    command   sftp-server(1M)   implements   the  sftp  file  
-   transfer  subsystem.  By  default,  no  subsystems   are   
+   transfer  subsystem.
+
+   Alternately the name ``internal-sftp'' implements an
+   in-process ``sftp'' server.  This may simplify
+   configurations using ChrootDirectory to force a different
+   filesystem root on clients.
+
+   By  default,  no  subsystems   are  
    defined. This option applies to protocol version 2 only. 

As a last note, as of now, we do not plan to backport this to Solaris 10.