On 02/21/2015 12:42 AM, Christoph Anton Mitterer wrote:
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.
Yes, the debugging is quite tricky, if you use -ddd you see more
temporary sessions allocated and cleaned (to make sure there will be
place to accommodate and to store some ongoing data?), but they do not
persist through all your connection.
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".
It should be only for mux (if I'm wrong, correct me). From man:
>> ... sessions permitted per network connection
which is use case of multiplexed connection.
What is the issue you guys found?
It was combination of (forced)command, pty and auditing. This
combination was using 2 sessions instead of one and if there was
MaxSessions 2, second connection took down even the first one.
Best regards,
Jakub
Cheers,
Chris.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
