openssh unix dev - Feb 2015 - which are the exact effects of MaxSessions

Hey.

I wondered a bit which the exact effects of MaxSessions are.

The documentation says:
        Specifies the maximum number of open sessions permitted per net?
        work connection.  The default is 10.


And it apparently seems that setting e.g. the following in sshd_config:
  MaxSessions 0
     => no logins possible at all

  MaxSessions 1
     => control channel muxing basically forbidden from the server side

  MaxSessions n
     => at most n sessions may use a mux, including the one which
        initiated it
        but further muxes (with again n session) may be created by that
        client


Is it just that? Or are there any other side effects which I can't see?


Thanks,
Chris.

btw: Would be nice if something like the above could be added to the
manpage for clraification :)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150220/9aeb08ce/attachment.bin>

Hello,
According my observation, MaxSessions 1 works for opening only one 
session through multiplexed channel, which degrades multiplexed 
connection back to only one session. MaxSessions 0 doesn't make much sense.

I don't know if you use openssh from some distribution, but in RHEL we 
had recently one bug in audit which looks similar like your issue -- 
with MaxSessions 1 sshd was preventing to log you in.

On 02/20/2015 02:51 AM, Christoph Anton Mitterer wrote:
> Hey.
>
> I wondered a bit which the exact effects of MaxSessions are.
>
> The documentation says:
>          Specifies the maximum number of open sessions permitted per net?
>          work connection.  The default is 10.
>
>
> And it apparently seems that setting e.g. the following in sshd_config:
>    MaxSessions 0
>       => no logins possible at all
>
>    MaxSessions 1
>       => control channel muxing basically forbidden from the server side
>
>    MaxSessions n
>       => at most n sessions may use a mux, including the one which
>          initiated it
>          but further muxes (with again n session) may be created by that
>          client
>
>
> Is it just that? Or are there any other side effects which I can't see?
Yes, it should be like this. Basically it is meant to have max N 
interactive sessions in that connection initiated by mux. If you try to 
connect using "ssh -T", pty is not allocated and this doesn't
count as a
session (not sure if it is bug or feature -- reproducible with vanilla 
sources). Damien?

Greetings,
Jakub
>
>
> Thanks,
> Chris.
>
> btw: Would be nice if something like the above could be added to the
> manpage for clraification :)
>
>
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Fri, 2015-02-20 at 08:09 +0100, Jakub Jelen wrote: 
> According my observation, MaxSessions 1 works for opening only one 
> session through multiplexed channel, which degrades multiplexed 
> connection back to only one session.
Well one get's still a mux process and also the messages (when debugging
is on) on the "master sesssion" that others try to re-use it... but
then
they're blocked.
> I don't know if you use openssh from some distribution
Debian.
> , but in RHEL we 
> had recently one bug in audit which looks similar like your issue -- 
> with MaxSessions 1 sshd was preventing to log you in.
Well I don't really think I have any issues... I just wondered whether
there are any other side-effects than having influence on the channel
muxing ... perhaps something like "only accept 1 session from the same
IP, even when not muxing".

What is the issue you guys found?


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150221/e64c9ee3/attachment.bin>