https://bugzilla.mindrot.org/show_bug.cgi?id=3662
Bug ID: 3662
Summary: Make logging of chrooted sftp sessions possible
internally routed to local file, without /dev/log
device
Product: Portable OpenSSH
Version: 9.6p1
Hardware: amd64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component: sftp-server
Assignee: unassigned-bugs@mindrot.org
Reporter: daku8938@gmx.de
Problem:
Abstract:
If you have two or more sftp-servers and the sftp user's home directory
is on one nfs share (exported by a third party NFS server), you have to
make a local bind mount over each chrooted user's /dev/log file to be
able to log the sftp sessions on all sftp servers.
If you have now 1000 or more users and therefore 1000 or more local
bind units, the system becomes slow because it does not scale.
(see e.g. https://github.com/systemd/systemd/issues/31137)
So it would be great if the sftp session log of a user session could be
routed internally directly e.g. to a local file "/var/log/sftp/%u.log"
Here the problem and the current ugly and non-scaling inperformant
workaround. You can see it also here:
https://unix.stackexchange.com/questions/666641/howto-log-multiple-sftpd-servers-activity-which-users-chrooted-home-is-on-shar
I have an Ubuntu server with sftpd running where /var/data/chroot/ is
an NFS mount from a remote central NFS server, and each sftpd user's
chroot home is /var/data/chroot/<username>/ and every user has a log
device /var/data/chroot/<username>/dev/log which I read in successfully
with syslog-ng:
source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
destination d_sftp_<username> { file("/var/log/sftp/<username>.log");
};
Now I have a second sftpd server in parallel, with the same user
database and also mounts /var/data/chroot/ via NFS, and has the same
syslog-ng config, so every user can login on the one server or on the
other. This is for high availability. This works so far.
What is not working now is the sftpd logging: The sftp user's log is
only available on one sftp server exclusively, and that is the one
where syslog-ng was started least, because as I understand it takes the
exclusive unix socket file lock for each user's /dev/log.
So, if a user logs in on the first server, where syslog-ng was started
least, the user's sftp activity is logged on the first server. But if
the user logs in on the second server, it's sftp activity is not
logged, neither on the second nor on the first server.
If the syslog-ng is then restarted on the second server, the sftp
user's activity is exclusively logged only on the second server and
only for logins on the second server.
My ugly workaround for this is the following:
Create a local directory under which user subdirectories are created:
sudo mkdir /var/data/dev For very username <username> and the user's
primary group <groupname> do the following:
sudo mkdir /var/data/dev/<username>
sudo chmod 550 /var/data/dev/<username> # This
restrictive permission is a requirement I think
sudo chgrp <groupname> /var/data/dev/<username> # so the user can
read the directory
So the new directory is exactly the same as the existing
/var/data/chroot/<username>/dev directory (which is on the nfs mount
/var/data/chroot/).
Then do mount --bind /var/data/dev/<username>
/var/data/chroot/<username>/dev so /var/data/chroot/<username>/dev is
now effectively local on the sftp server, not anymore on nfs mount.
Then change the syslog-ng config
from
source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
to
source s_chroot_<username> { unix-stream("/var/data/dev/<username>/log"
optional(yes) ); };
(this is not strictly needed, but I think it's nice having syslog-ng
definitely now only reading from local file, guaranteed not from nfs
mount anymore)
Whether the user logs in on the one sftp server or the other, syslog-ng
can now log the sftp session on the affected sftp server.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
Bug ID: 3662
Summary: Make logging of chrooted sftp sessions possible
internally routed to local file, without /dev/log
device
Product: Portable OpenSSH
Version: 9.6p1
Hardware: amd64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component: sftp-server
Assignee: unassigned-bugs@mindrot.org
Reporter: daku8938@gmx.de
Problem:
Abstract:
If you have two or more sftp-servers and the sftp user's home directory
is on one nfs share (exported by a third party NFS server), you have to
make a local bind mount over each chrooted user's /dev/log file to be
able to log the sftp sessions on all sftp servers.
If you have now 1000 or more users and therefore 1000 or more local
bind units, the system becomes slow because it does not scale.
(see e.g. https://github.com/systemd/systemd/issues/31137)
So it would be great if the sftp session log of a user session could be
routed internally directly e.g. to a local file "/var/log/sftp/%u.log"
Here the problem and the current ugly and non-scaling inperformant
workaround. You can see it also here:
https://unix.stackexchange.com/questions/666641/howto-log-multiple-sftpd-servers-activity-which-users-chrooted-home-is-on-shar
I have an Ubuntu server with sftpd running where /var/data/chroot/ is
an NFS mount from a remote central NFS server, and each sftpd user's
chroot home is /var/data/chroot/<username>/ and every user has a log
device /var/data/chroot/<username>/dev/log which I read in successfully
with syslog-ng:
source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
destination d_sftp_<username> { file("/var/log/sftp/<username>.log");
};
Now I have a second sftpd server in parallel, with the same user
database and also mounts /var/data/chroot/ via NFS, and has the same
syslog-ng config, so every user can login on the one server or on the
other. This is for high availability. This works so far.
What is not working now is the sftpd logging: The sftp user's log is
only available on one sftp server exclusively, and that is the one
where syslog-ng was started least, because as I understand it takes the
exclusive unix socket file lock for each user's /dev/log.
So, if a user logs in on the first server, where syslog-ng was started
least, the user's sftp activity is logged on the first server. But if
the user logs in on the second server, it's sftp activity is not
logged, neither on the second nor on the first server.
If the syslog-ng is then restarted on the second server, the sftp
user's activity is exclusively logged only on the second server and
only for logins on the second server.
My ugly workaround for this is the following:
Create a local directory under which user subdirectories are created:
sudo mkdir /var/data/dev For very username <username> and the user's
primary group <groupname> do the following:
sudo mkdir /var/data/dev/<username>
sudo chmod 550 /var/data/dev/<username> # This
restrictive permission is a requirement I think
sudo chgrp <groupname> /var/data/dev/<username> # so the user can
read the directory
So the new directory is exactly the same as the existing
/var/data/chroot/<username>/dev directory (which is on the nfs mount
/var/data/chroot/).
Then do mount --bind /var/data/dev/<username>
/var/data/chroot/<username>/dev so /var/data/chroot/<username>/dev is
now effectively local on the sftp server, not anymore on nfs mount.
Then change the syslog-ng config
from
source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
to
source s_chroot_<username> { unix-stream("/var/data/dev/<username>/log"
optional(yes) ); };
(this is not strictly needed, but I think it's nice having syslog-ng
definitely now only reading from local file, guaranteed not from nfs
mount anymore)
Whether the user logs in on the one sftp server or the other, syslog-ng
can now log the sftp session on the affected sftp server.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs