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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
