Howto log multiple sftpd instances with their chroot shared via NFS

[Jochen Bern]

On 28.09.21 17:00, Hildegard Meier wrote:
> Each sftp customer's sftp activity needs to be available in a
> dedicated log file for each sftp customer, for our support to
> be able to look into it. Here is an example of this log file:
> 
> Sep 28 15:54:25 myhostname internal-sftp[1618]:
>     session opened for local user <username> from [1.2.3.4]

(General warning from me: There are log messages from the user's session 
*earlier* than that, from before the client successfully authenticated 
for the login as <username>. Having those messages go into a per-account 
log(file) is nontrivial because sshd *does not yet know* what username 
it will be, and if your support staff cannot see those lines, they will 
not be able to debug *failed* connection attempts.)

At this point, I'd say that the best approach would be to have the 
post-auth sftp-server process log to a *file* within the chroot, with 
the filename set to the server's hostname (in the ForceCommand statement 
of the server's /etc/ssh/sshd_config). Unfortunately, while sftp-server 
has command line options for logging to syslog and for logging to 
stderr, it does *not* have a command line option to log to a *file* (or, 
for that matter, to set/change the "ident" parameter of openlog(3) to 
include the username) ...

> you have a global sftpd log (I think in /var/log/messages on the
> server or something like that)

(RHEL, Centos, Fedora etc. tend to have a /var/log/messages . Ubuntu, in 
my experience, uses /var/log/syslog instead.)

> But I think this is not trivial to make this reliable and robust,
> since we need to parse the process id (sftpd session), check which
> username that session belongs to and write that log lines in the
> username specific log file.

That's essentially what tools like opentelemetry.io are talking about 
when they make a difference between "logs" and "traces", but I suppose 
that throwing one of those at your problem could easily prove to be 
overkill ...

https://opentelemetry.io/docs/concepts/data-sources/

> A problem would be e.g. if the user never logs out, and the log file
> rotates daily, so after one day, the parser could not find any
> "session opened for local user xxx" log lines anymore.

That's why log-parsing utilities that are worth their salt (logwatch, 
ConSol's check_logfiles, etc.) can be configured to find and include the 
rotated-away previous logfile instances ...

> as I understand it is hard coded in the system C library that the
> log devices name is /dev/log, so this cannot be changed

Well, not on Linux, at least ...

[still fondly remembers AIX "softlinks" where you could "ln -s" 
something to "/foo/$BAR/baz" and the value of the env var BAR would be 
taken into account at access/expansion time]

> But the problem is that the last started syslog-ng aquires the lock
> for the NFS shared /var/data/chroot/<username>/dev/log so the other
> server cannot read it anymore and so there is no sftp log for the
> sessions on the other server.

(I *still* suspect that if only you could configure the syslogd's to use 
a file locking method that just does *not* work across NFS shares - 
there's about half a dozen different methods available, see, e.g.,

https://dovecot.org/pipermail/dovecot/2011-July/060149.html

-, you could circumvent that effect from the get-go ...)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210928/5cad1cbe/attachment-0001.p7s>