SSHv2 sshd exit criteria

Nicolas Williams Nicolas.Williams at
Sat Oct 27 00:16:05 EST 2001

When should sshd disconnect an SSHv2 connection?

Markus Friedl says "for protocol v2 the client decides when to close the

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.

-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

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