openssh bugs - Dec 2016 - [Bug 2648] New: allow max connections config

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

            Bug ID: 2648
           Summary: allow max connections config
           Product: Portable OpenSSH
           Version: 7.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: DarkTrick at outlook.de

Current situation:
------------------
Currently one can not configure, that for example only 2 connections at
the should be allowed through ssh. If one want to set this restriction,
a OS wide restriction or script-trickery is needed 


Suggestion:
------------
Add new Config-options for:
- maximum allowed connections to the server
- maximum allowed connections to the server with a specified username



Example:
----------
maxConnectionsAllowedToServer: 3
maxConnectionsAllowedToServerWithUsername: root,2,guest,5

- outcome: a total number of 3 connections are allowed
- although 5 guest connections are set, the superior global value of 3
restricts that value


Reason for this Request:
-------------------------
Security. 
E.g: One could ensure, that only he is logged in on his server via ssh.
(without changing system restrictions for max-login number)

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

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
I don't think this is something we're interested in doing.  A new sshd
process has very little knowledge of the other running sshds on the
system and adding it would add a lot of complexity for little benefit.

Since you're running Linux, you probably want to look at pam_limits,
especially the maxlogins and maxsyslogins items.

http://www.linux-pam.org/Linux-PAM-html/sag-pam_limits.html

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

--- Comment #2 from DarkTrick <DarkTrick at outlook.de> ---
I didn't expect it to be such a complex request. I was expecting some
central ssh-request receiver, that has knowledge of that. 

Actually I'm currently using maxlogins for that. But this makes a
system change necessary, which I would'nt say is good smelling way.

Anyway, thank you very much for your reply, so I know I should somehow
deal without this feature :) 

best regards and keep up the good work! :)

-- 
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.

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to DarkTrick from comment #2)
> I didn't expect it to be such a complex request. I was expecting
> some central ssh-request receiver, that has knowledge of that. 
There is a central process that receives the connections, but it
immediately forks of a new process to handle the connection.  That
child process has to do quite a bit of protocol work before it finds
out what the username is.

There's a very limited feedback mechanism between those those
processes: a pipe that's closed when the child is either authenticated
or the child dies  which is used to implement MaxStartups.  If you were
going to implement this you'd probably extend those to provide more
information and provide a go/no go decision to the child, but you'd
also have to add a mechanism to catch when the user logs out, keep
track of the counts and do option parsing.

Thanks for the suggestion, but as I said I don't think it's worth the
complexity to implement given that many OSes already implement
something like it.

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.