Hi, We need to limit concurrent sftp logins to one per user (because of bad client behaviour). Is there any way to achieve this I have overlooked? It seems it could be possible with pam_limits, if sftp sessions were recorded in utmp (a guess from what I found googling around). If I configure /etc/security/limits.conf with testuser hard maxlogins 1 and connect with ssh, and try a second connection with sftp, the sftp fails because there is already one session open. But if I connect with sftp and try a second sftp connection, it is allowed. Is there some way to have sftp connections recorded in utmp? I haven't found any reference to this. There are some posts from 10+ years ago where others were trying the same thing but there's no reply about how to do it. Would it be possible to add this option? We're using ChrootDirectory and ForceCommand internal-sftp, if it makes a difference (I've tried without and had the same results). Tried this on Debian bookworm's openssh-server (9.2). The changelog from 9.3 does not mention anything related to this. Thank you, Fran?ois
I've been battling similar issues, and the only methods I've found (with sftp) was to use software like pureftd or crushftp (using crushftp lately as production) that does handle these issues "out of the box" Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessions> On 30 Mar 2023, at 22:43, Fran?ois Ouellet <franco at sol.mpact.tv> wrote: > > Hi, > > We need to limit concurrent sftp logins to one per user (because of bad > client behaviour). Is there any way to achieve this I have overlooked? > > It seems it could be possible with pam_limits, if sftp sessions were > recorded in utmp (a guess from what I found googling around). If I > configure /etc/security/limits.conf with > > testuser hard maxlogins 1 > > and connect with ssh, and try a second connection with sftp, the sftp > fails because there is already one session open. But if I connect with > sftp and try a second sftp connection, it is allowed. > > Is there some way to have sftp connections recorded in utmp? I haven't > found any reference to this. There are some posts from 10+ years ago > where others were trying the same thing but there's no reply about how > to do it. Would it be possible to add this option? > > We're using ChrootDirectory and ForceCommand internal-sftp, if it makes > a difference (I've tried without and had the same results). > > Tried this on Debian bookworm's openssh-server (9.2). The changelog > from 9.3 does not mention anything related to this. > > Thank you, > > Fran?ois > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
hvjunk wrote this message on Thu, Mar 30, 2023 at 23:12 +0200:> I've been battling similar issues, and the only methods I've found (with sftp) was to use > software like pureftd or crushftp (using crushftp lately as production) that does handle these > issues "out of the box" > Other than that, I'd expect you'll need to write your own PAM modules to track the accounting part to > enforce the limits yourself, as you'll need to account for the sftp different from the terminal sessionsYou could use an sftp-server wrapper script that creates a lock file/dir or another way to detect if a connection is already present, and then force the use of that script via the sshd_config Subsystem directive.> > On 30 Mar 2023, at 22:43, Fran?ois Ouellet <franco at sol.mpact.tv> wrote: > > > > Hi, > > > > We need to limit concurrent sftp logins to one per user (because of bad > > client behaviour). Is there any way to achieve this I have overlooked? > > > > It seems it could be possible with pam_limits, if sftp sessions were > > recorded in utmp (a guess from what I found googling around). If I > > configure /etc/security/limits.conf with > > > > testuser hard maxlogins 1 > > > > and connect with ssh, and try a second connection with sftp, the sftp > > fails because there is already one session open. But if I connect with > > sftp and try a second sftp connection, it is allowed. > > > > Is there some way to have sftp connections recorded in utmp? I haven't > > found any reference to this. There are some posts from 10+ years ago > > where others were trying the same thing but there's no reply about how > > to do it. Would it be possible to add this option? > > > > We're using ChrootDirectory and ForceCommand internal-sftp, if it makes > > a difference (I've tried without and had the same results). > > > > Tried this on Debian bookworm's openssh-server (9.2). The changelog > > from 9.3 does not mention anything related to this.-- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
On Thu, 30 Mar 2023, Fran?ois Ouellet wrote:> Hi, > > We need to limit concurrent sftp logins to one per user (because of bad > client behaviour). Is there any way to achieve this I have overlooked? > > It seems it could be possible with pam_limits, if sftp sessions were > recorded in utmp (a guess from what I found googling around). If I > configure /etc/security/limits.conf with > > testuser hard maxlogins 1 > > and connect with ssh, and try a second connection with sftp, the sftp > fails because there is already one session open. But if I connect with > sftp and try a second sftp connection, it is allowed. > > Is there some way to have sftp connections recorded in utmp? I haven't > found any reference to this. There are some posts from 10+ years ago > where others were trying the same thing but there's no reply about how > to do it. Would it be possible to add this option?We've been asked about this a number of times before - the problem is that utmp is really set up to record interactive logins that have a TTY/PTY assigned. There is AFAIK no real standard for recording "service logins" (e.g. sftp or SSH command execution w/o TTY) in utmp and many OS utmp implementation lack fields by which this could be communicated. IIRC we toyed with recording something fake like "sftp" in ut_line but that caused problems as none of the other tools were set up to accept it. -d