https://bugzilla.mindrot.org/show_bug.cgi?id=3723
S Zhang <szh...@gen-info.osaka-u.ac.jp> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from S Zhang <szh...@gen-info.osaka-u.ac.jp> ---
A quick recap on what the three components I suspected were up to:
linux-pam side provided the pam_limit.so that offers a session module
only to limit how many concurrent login a user can have. They based
their session count on the utmp version of session, and correctly
failed the session on the pam stack.
openssh side considered that the login succeeded the auth stack, and
accordingly spawned a sshd_session process under the user. It respected
the failed session and restricted such session to not able to do
anything including port forwarding.
systemd side created a session as there is a process of sshd_session,
even though that it failed the PAM session part. That at least
guaranteed the process being put under the user's cgroup before it got
overwhelmed.
It seems that everyone in openssh, systemd, and linux-pam is doing the
right thing. It is just unfortunate that this combination had a
discrepancy on how utmp count differs than systemd-logind count, the
pam_limits.so failed session is not considered a failed auth, and I
lacked the functionality of stopping a user from creating too many
systemd-logind session that resulted in a DoS in my server.
I would close this issue right now. Now I think I had a better
understanding on what happened to all this session mess that I caught
into.
Thanks for pointing out that UnusedConnectionTimeout option. It would
correctly close such useless but troubling session in my test server,
though I probably need to wait a few more years before the production
server currently running RHEL 8/9 can benefit from it.
Maybe I should also consider modifying the pam_limits.so to provide an
auth module to disallow logins exceeding the session limit.
--
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
