Exiting ssh when MaxSessions=0 - openssh

This is a discussion on Exiting ssh when MaxSessions=0 - openssh ; On Fri, 29 Aug 2008, Iain Morgan wrote: > Hi, > > I've been experimenting with MaxSessions=0 in the sshd_config and have > encountered one unfortunate problem. Once the client authenticates to > the server, it ceases to respond to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Exiting ssh when MaxSessions=0

  1. Re: Exiting ssh when MaxSessions=0

    On Fri, 29 Aug 2008, Iain Morgan wrote:

    > Hi,
    >
    > I've been experimenting with MaxSessions=0 in the sshd_config and have
    > encountered one unfortunate problem. Once the client authenticates to
    > the server, it ceases to respond to keyboard input.
    >
    > At first glance, it looks like the client is in a hung state and does
    > not time out. If port forwarding was requested on the command-line and
    > the server accepts the request, that continues to work. But the tilde
    > escapes (and ^C) do not work. Apparently, you have to kill the session
    > from another terminal.
    >
    > Once the session is killed, any buffered input is handled by the shell.
    >
    > In cases where you know the server will have MaxSessions=0, this is not
    > a huge issue; you just have to remember to use the -f option. It is a
    > bit unfortunate if you forget to use -f.
    >
    > It would be nice if ~. worked in this situation. I suppose ~C would also
    > be nice in order to add port forwardings after the fact. I'm not sure if
    > it would be problematic to add such support.


    Yes, this is a bug. I think this patch fixes it, but I need to think
    though the consequences more:

    Index: channels.c
    ================================================== =================
    RCS file: /var/cvs/openssh/channels.c,v
    retrieving revision 1.273
    diff -u -p -r1.273 channels.c
    --- channels.c 16 Jul 2008 12:42:06 -0000 1.273
    +++ channels.c 29 Aug 2008 19:25:04 -0000
    @@ -2311,8 +2311,8 @@ channel_input_open_failure(int type, u_i
    xfree(lang);
    }
    packet_check_eom();
    - /* Free the channel. This will also close the socket. */
    - channel_free(c);
    + /* Schedule the channel for cleanup/deletion. */
    + chan_mark_dead(c);
    }

    /* ARGSUSED */

    The difference if you are curious, is that chan_mark_dead() will schedule
    the channel for asynchronous cleanup, via channel_garbage_collect().
    That path runs the channel->detach_user callback which is what we rely
    on to determine that our main session channel has exited.

    channel_free() doesn't run any callbacks, so we never noticed that the
    session channel went away.

    -d

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Exiting ssh when MaxSessions=0

    Hi,

    I've been experimenting with MaxSessions=0 in the sshd_config and have
    encountered one unfortunate problem. Once the client authenticates to
    the server, it ceases to respond to keyboard input.

    At first glance, it looks like the client is in a hung state and does
    not time out. If port forwarding was requested on the command-line and
    the server accepts the request, that continues to work. But the tilde
    escapes (and ^C) do not work. Apparently, you have to kill the session
    from another terminal.

    Once the session is killed, any buffered input is handled by the shell.

    In cases where you know the server will have MaxSessions=0, this is not
    a huge issue; you just have to remember to use the -f option. It is a
    bit unfortunate if you forget to use -f.

    It would be nice if ~. worked in this situation. I suppose ~C would also
    be nice in order to add port forwardings after the fact. I'm not sure if
    it would be problematic to add such support.

    --
    Iain Morgan
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Exiting ssh when MaxSessions=0

    Damien Miller wrote:
    > On Fri, 29 Aug 2008, Iain Morgan wrote:
    >
    >> Hi,
    >>
    >> I've been experimenting with MaxSessions=0 in the sshd_config and have
    >> encountered one unfortunate problem. Once the client authenticates to
    >> the server, it ceases to respond to keyboard input.
    >>
    >> At first glance, it looks like the client is in a hung state and does
    >> not time out. If port forwarding was requested on the command-line and
    >> the server accepts the request, that continues to work. But the tilde
    >> escapes (and ^C) do not work. Apparently, you have to kill the session
    >> from another terminal.
    >>
    >> Once the session is killed, any buffered input is handled by the shell.
    >>
    >> In cases where you know the server will have MaxSessions=0, this is not
    >> a huge issue; you just have to remember to use the -f option. It is a
    >> bit unfortunate if you forget to use -f.


    As a workaround if you need this behaviour: you can set "ForceCommand
    /bin/true" instead of "MaxSessions 0". This will allow the channel
    requests to succeed without letting the user actually do anything.

    >> It would be nice if ~. worked in this situation. I suppose ~C would also
    >> be nice in order to add port forwardings after the fact. I'm not sure if
    >> it would be problematic to add such support.

    >
    > Yes, this is a bug. I think this patch fixes it, but I need to think
    > though the consequences more:
    >
    > Index: channels.c
    > ================================================== =================
    > RCS file: /var/cvs/openssh/channels.c,v
    > retrieving revision 1.273
    > diff -u -p -r1.273 channels.c
    > --- channels.c 16 Jul 2008 12:42:06 -0000 1.273
    > +++ channels.c 29 Aug 2008 19:25:04 -0000
    > @@ -2311,8 +2311,8 @@ channel_input_open_failure(int type, u_i
    > xfree(lang);
    > }
    > packet_check_eom();
    > - /* Free the channel. This will also close the socket. */
    > - channel_free(c);
    > + /* Schedule the channel for cleanup/deletion. */
    > + chan_mark_dead(c);
    > }
    >
    > /* ARGSUSED */
    >
    > The difference if you are curious, is that chan_mark_dead() will schedule
    > the channel for asynchronous cleanup, via channel_garbage_collect().
    > That path runs the channel->detach_user callback which is what we rely
    > on to determine that our main session channel has exited.
    >
    > channel_free() doesn't run any callbacks, so we never noticed that the
    > session channel went away.


    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: Exiting ssh when MaxSessions=0

    On Tue, 2 Sep 2008, Iain Morgan wrote:

    > Thanks Damien. Do you need me to submit a bug on this for tracking
    > purposes?


    Yes, please!

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: Exiting ssh when MaxSessions=0

    On Sat, Aug 30, 2008 at 05:30:11 +1000, Damien Miller wrote:
    > On Fri, 29 Aug 2008, Iain Morgan wrote:
    >
    > > Hi,
    > >
    > > I've been experimenting with MaxSessions=0 in the sshd_config and have
    > > encountered one unfortunate problem. Once the client authenticates to
    > > the server, it ceases to respond to keyboard input.
    > >
    > > At first glance, it looks like the client is in a hung state and does
    > > not time out. If port forwarding was requested on the command-line and
    > > the server accepts the request, that continues to work. But the tilde
    > > escapes (and ^C) do not work. Apparently, you have to kill the session
    > > from another terminal.
    > >
    > > Once the session is killed, any buffered input is handled by the shell.
    > >
    > > In cases where you know the server will have MaxSessions=0, this is not
    > > a huge issue; you just have to remember to use the -f option. It is a
    > > bit unfortunate if you forget to use -f.
    > >
    > > It would be nice if ~. worked in this situation. I suppose ~C would also
    > > be nice in order to add port forwardings after the fact. I'm not sure if
    > > it would be problematic to add such support.

    >
    > Yes, this is a bug. I think this patch fixes it, but I need to think
    > though the consequences more:
    >
    > Index: channels.c
    > ================================================== =================
    > RCS file: /var/cvs/openssh/channels.c,v
    > retrieving revision 1.273
    > diff -u -p -r1.273 channels.c
    > --- channels.c 16 Jul 2008 12:42:06 -0000 1.273
    > +++ channels.c 29 Aug 2008 19:25:04 -0000
    > @@ -2311,8 +2311,8 @@ channel_input_open_failure(int type, u_i
    > xfree(lang);
    > }
    > packet_check_eom();
    > - /* Free the channel. This will also close the socket. */
    > - channel_free(c);
    > + /* Schedule the channel for cleanup/deletion. */
    > + chan_mark_dead(c);
    > }
    >
    > /* ARGSUSED */
    >
    > The difference if you are curious, is that chan_mark_dead() will schedule
    > the channel for asynchronous cleanup, via channel_garbage_collect().
    > That path runs the channel->detach_user callback which is what we rely
    > on to determine that our main session channel has exited.
    >
    > channel_free() doesn't run any callbacks, so we never noticed that the
    > session channel went away.
    >
    > -d
    >
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev


    Thanks Damien. Do you need me to submit a bug on this for tracking
    purposes?

    --
    Iain Morgan
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread