[Bug 3723] New: sshd failed to close session when client specifies no remote command

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Mon Aug 26 17:20:12 AEST 2024


https://bugzilla.mindrot.org/show_bug.cgi?id=3723

            Bug ID: 3723
           Summary: sshd failed to close session when client specifies no
                    remote command
           Product: Portable OpenSSH
           Version: 8.0p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: PAM support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: szhang at gen-info.osaka-u.ac.jp

We limit the number of sessions a user can close using pam_limits.so by
setting maxlogins in /etc/security/limits.conf

This works well when user tries to start a normal ssh session or sftp
session. They would be told about Too many logins, or Received message
too long and the session with the client would close.

However if the user specified -N, things go differently. No error
message would be shown even though the user failed pam_limits.so on
session creation. The connection persists, although port forwarding
would fail for being administratively prohibited.

To make matters worse, systemd would consider such failed session "a
session", and create a scope for it. It would show up on the loginctl
output, but not on the "w".

systemd has a limit on all sessions in the system it could handle, and
such "failed session" counted against such limit. Thus, a user with ssh
access could potentially create 8192 sessions through ssh -T to such
machine, disregarding any limitation set on pam_limits regarding the
maxlogins, flooding the systemd, and denying any other legit user from
creating a systemd-managed session to launch gnome and other software.

I wonder if such behavior is by design, or if there is anything I could
do to make sshd kill such session if it failed pam_limits.so on session
creation, even if no subprocess would be launched.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list