SSHv2 sshd exit criteria
Nicolas Williams
Nicolas.Williams at ubsw.com
Sat Oct 27 00:32:34 EST 2001
Oh, never mind. I think I just saw some light...
Yes, the client should be the one to decide that one session is all it
wanted, and the client finds out when that session ends, and the client
knows the status of each channel, so the client *can* choose.
So, never mind. My apologies for wasting your time, and bandwidth.
Nico
On Fri, Oct 26, 2001 at 10:16:05AM -0400, Nicolas Williams wrote:
> When should sshd disconnect an SSHv2 connection?
>
> Markus Friedl says "for protocol v2 the client decides when to close the
> connection."
>
> In principle, I agree, because SSHv2 supports multiple sessions over the
> same connection, with the client able to launch new sessions anytime
> then it should be upto the client.
>
> But this would be a major cultural change for most users, and would
> break any useage of SSHv2 for batch purposes.
>
> So perhaps the sshd exit criteria ought to be defined.
>
> I propose that, if the client never started any session other than the
> default session, and if the session ended, and there are no more open
> channels, then sshd should exit. But, if the client did open more than
> one session, then sshd should not exit, even if there are no more
> sessions in use and no more open channels. Fatal errors aside.
>
> Nico
> --
> -DISCLAIMER: an automatically appended disclaimer may follow. By posting-
> -to a public e-mail mailing list I hereby grant permission to distribute-
> -and copy this message.-
>
> Visit our website at http://www.ubswarburg.com
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission. If
> verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
--
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the openssh-unix-dev
mailing list