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)
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
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! :)
(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.
closing resolved bugs as of 8.6p1 release