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