sftp syslogging does not work if sftp sessions are within a chroot

This document (7016993) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12

SUSE Linux Enterprise Server 11

Situation

In /etc/ssh/sshd_config, sftp sessions have been set to log extra details about what operations are performed. This works unless the session in question is for a user that has been chrooted. (See TID 7009112 for instructions on how to chroot sftp.)

Resolution

A listening socket must exist within the chroot directory for sftp session messages to be logged. Normally, the system logger's default socket is at /dev/log which is outside of the chroot directory. However, additional sockets located inside chroot directory can be added or default socket could be "propagated" into chroot directory.

SLES 11

To have syslog-ng create extra sockets, use the following syntax in /etc/sysconfig/syslog:

SYSLOGD_ADDITIONAL_SOCKET_unique1="/chrootdirectory/dev/log"

Where "unique1" is a unique name associated with this one socket. If all users are chrooted into one location, one unique socket is enough. However, if there are multiple chroot locations, a socket is needed for each location, and the name give to this variable should be unique for each one. For example, if each user has their own chroot location, it may be preferred to replace "unique1" above with the username in question. (Though that is arbitrary... the only requirement is that each additional socket is named uniquely.)

Also, "/chrootdirectory" as listed above needs to be replaced with the full path to the chroot location which is specified in /etc/ssh/sshd_config. Sometimes variables are used in sshd_config to make unique configurations for multiple users easier, but in /etc/sysconfig/syslog, each path must be explicitly defined.

Underneath the /chrootdirectory, manually create a ./dev directory, but do not create the log file manually.

Then restart syslog-ng with "rcsyslog restart".

Each additional socket defined is translated (by the script /etc/init.d/syslog) into a "-a /path" parameter and added to the syslog-ng command line. If a large number of different chroot locations and sockets are required, it is possible that limitations of syslog-ng (or of the command line buffer) may be encountered. The author of this document has not tested scalability.

NOTE: If Apparmor is enabled, it can block the ability of syslog to create sockets in non-standard locations. In that case, the error "permission denied" would be seen upon starting syslog-ng. To allow Apparmor and extra syslog-ng sockets to co-exist, /etc/apparmor.d/sbin.syslog-ng can be modified to allow writing at additional paths.

SLES 12, SLES 15

rsyslog

To have rsyslog create extra sockets, edit /etc/rsyslog.conf. Find the line:

$ModLoad imuxsock.so

(It should be there and in effect by default. If it is missing or remarked out, correct that.)

Anywhere AFTER that line, add the line:

$AddUnixListenSocket /chrootdirectory/dev/log

If all chrooted users share one location, one additional socket is enough. However, if there are multiple chroot locations, a socket will be needed for each location.

Also, "/chrootdirectory" as listed above needs to be replaced with the full path to the chroot location which is specified in /etc/ssh/sshd_config. Sometimes variables are used in sshd_config to make unique configurations for multiple users easier, but in /etc/rsyslog.conf, each path must be explicitly defined.

Underneath the /chrootdirectory, manually create a ./dev directory, but do not create the log file manually.

Then restart rsyslog service with "systemctl restart rsyslog".

systemd-journald

Since the main system logger is systemd-journald, another approach could be to use it exclusively for messages of SFTP sessions. This approach will "propagate" /dev/log into chrooted directory via "bind" mount.

Creation of /dev/log inside chroot directory

Let's use systemd-tmpfiles(8) to create needed directory, file for us (see tmpfiles.d(5) for details). For each chrooted directory add following lines into /etc/tmpfiles.d/sftp-server.conf:

D! /chrootdirectory/dev 775 root root - -
f! /chrootdirectory/dev/log 666 root root - -

The above lines instruct systemd-tmpfiles to create a clean /chrootdirectory/dev directory and auxiliary /chrootdirectory/dev/log during boot.

Definitions of bind mounts

Let's use systemd.mount(5) unit definition to define "propagation" of system's /dev/log into the chroot directory. This unit must be created for each chroot directory.

Here /etc/systemd/system/chrootdirectory-dev-log.mount will be created with following content:

[Mount]
What=/dev/log
Where=/chrootdirectory/dev/log
Type=none
Options=bind,nofail,noauto

NOTE: With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. Moreover the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully.

Extending ssh.service unit for bind mounts

Now it is needed to make sshd.service unit require the previously defined bind mounts. Run systemctl edit sshd.service and add following content (RequiresMountsFor is space-separated list of absolute paths).

[Unit]
RequiresMountsFor=/chrootdirectory/dev/log

Finalization

During system boot everything will be setup automatically - temporary dev directory and auxiliary log file will be created in chroot directory, starting of sshd.service will bind-mount system /dev/log into chroot directories.

If reboot is not wanted then the steps to finalize the system-journal approach is

systemctl daemon-reload
systemd-tmpfiles --prefix=/chrootdirectory --create --remove --boot -E

to create tempory directory and auxiliary file,

systemctl restart sshd.service

to make sshd.service unit bind-mount /dev/log into chroot directories.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.