$ man sshd_config
[code]
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. All components of the path‐
name must be root-owned directories that are not writable by any other user or group. After the chroot,
sshd(8) changes the working directory to the user’s home directory.
The pathname 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 session this requires at least a shell, typically sh(1), and basic /dev nodes such as
null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and tty(4) devices. For file transfer ses‐
sions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp
server is used, though sessions which use logging may require /dev/log inside the chroot directory on
some operating systems (see sftp-server(8) for details).
The default is not to chroot(2).[/code]
Le minimum nécessaire à la session de l’utilisateur doit s’y trouver. Ça veut dire qu’au sein du chroot il faut reproduire un environnement minimal avec son /bin, /dev …
Que tu y mettes le binaire su dépend de toi.
À titre personnel, nous ne mettrions pas de su parce que nous estimons que c’est contradictoire à l’interêt de chroot.
L’interêt de chroot en ssh tel que nous le percevons est de restreindre les utilisateurs à une cage où ils seront libres de fureter dans le sentier balisé sans pouvoir fourrer le nez, accéder aux données hors de la cage. À ce titre, laisser installer/désinstaller dans la cage nous semble d’un interêt discutable.
X11Forwarding yes : graphique possible, option -X en ssh.
