> On 03 Apr 2023, at 15:44, François Ouellet <franco@xxxxxxxxxxxx> wrote: > > Le Saturday, 1 April 2023, 02:06:04 EDT Philipp Marek a écrit : >> Set a max-process ulimit in /etc/security/limits.conf (using a group specification). >> >> For internal sftp 1, for external 2, I guess. > > > I'v seen this suggested before and I have tried it then. It doesn't > work with this particular config. I don't know why yet. It works when > I don't use the internal-sftp and ChrootDirectory. I *suspect* it's 'cause the process limits are (firstly) applied to the ssd, which then forks and load the sftp, thus it might not be seen as an sftp, but only a sshd process. Having worked with opensshd, and other solutions, opensshd isn't really meant to handle these bad actors...once the actor have been authenticated, and the connections are there, OPenSSH basically steps out of the picture, so this type of limiting I'm not expecting to be an openssh service nor function. When you have these type of issues, rather (and I'm doing it for these and other security related reasons) extract the sftp function for those file transfer type services, and put it on a dedicated program that will deal with these type of bad actors in more organized/designed manner. My goto (for file transfers) is the Commercially available CrushFTP (WELL priced for the number of users) and ProFTPd as an opensource option again designed for these type of handling of bad actors _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
