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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
