The ChrootDirectory option resynced to SunSSH

UPDATE 2009-11-20: the Match keyword option has been resynced so it's possible to use ChrootDirectory selectively on specific user accounts, for example.

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.

Comments:

This post made my day! Thank you!

Posted by Zachary Schneider on March 23, 2009 at 05:33 PM CET #

[Trackback] A new feature has found its way into OpenSolarisPSARC/2009/155 ChrootDirectory option for SunSSH server. Chrooting is one of the features of OpenSSH, that didn�t found its way into SunSSH for some time but that has changed now. It will be part of OpenS...

Posted by c0t0d0s0.org on March 24, 2009 at 07:49 AM CET #

Could you please tell me what specific Solaris 10 version is required and what patch # needs to be installed for this to work?

Thank you!

Posted by Eric Kimminau on August 03, 2009 at 08:57 AM CEST #

to Eric: as of now, we do not plan to backport ChrootDirectory option to S10. Please use your usual support channel to get more information.

Posted by Jan Pechanec on August 07, 2009 at 06:41 AM CEST #

I just tried this feature. Is there a way to specify per-user whether to use ChrootDirectory?

I want my friends to share files and in the same time I want to be able to ssh into my server to do administrative stuff. I created a new user "fsharing" and added ChrootDirectory /path/to/sharing/dir. When I sftp to my server as fsharing I get to /path/to/sharing/dir. Great! But the when I ssh with my admin account I also get there.. Is there a way to enable the feature only for "fsharing" user? Or is there a better way of achieving what I am looking for?

Thanks,
-Ilya

Posted by Ilya on November 09, 2009 at 02:34 PM CET #

to Ilya: the "Match" keyword from OpenSSH is coming to SunSSH soon. That's what you are looking for.

Posted by Jan on November 10, 2009 at 01:48 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Jan Pechanec

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today