Subject: Sending SSH_MSG_GLOBAL_REQUEST as keep-alive to the client

From: "denis bider" <[email-masked]>
Date: Sat, 6 Nov 2004 00:08:20 +0100

Hi everyone,

in our server we have had some problems with detecting broken sessions from
clients in the past - the underlying sockets layer would simply not report
the session being terminated although effectively it was dead - and we
didn't want to solve it with an inactivity timeout because for our purposes
that would have to be too long, so my solution was to implement a sort of
ping feature in the server: the server sends an SSH_MSG_GLOBAL_REQUEST of an
arbitrary (locally defined) type, and expects to receive either SUCCESS or
FAILURE from the client. If neither arrives, and no other data either, the
session is deemed to be broken, and is closed.

This works fine with all recent clients I have had the chance of testing.
However we have had some reports from customers using older versions of
OpenSSH, which seem to bomb out and disconnect when SSH_MSG_GLOBAL_REQUEST
is received. The misbehaving versions I am aware of include 2.9, a
prehistoric one but still fairly widely deployed, apparently.

I believe that our server's behavior is correct according to the
specification. [CONNECT] does not explicitly say that global requests should
be handled by the client gracefully, but it does seem to imply so in its
non-biased description of the general nature of the packet (section 4 -
Global Requests): it refers to 'originator' and 'recipient' rather than
client and server, which supports the view that it should be possible for
servers to also send global requests. Indeed, we also use similar
server-side requests for purposes other than broken session detection in our
products.

But seeing that clients may exist which cannot handle this message, might it
be prudent to add an explicit note in [CONNECT] stating that clients should
handle unrecognized global requests gracefully? The note could be this
(appended to the end of section 4 - Global Requests):

  Note that, while this document defines only request messages sent
  by client to server, a server MAY also send global requests to the client.
  Such request types may be defined by an external specification, by
  local convention or may be sent with merely the intention of eliciting
  a response in order to validate that a session is still active. A client
  MUST gracefully handle unrecognized global requests by ignoring
  them and sending an SSH_MSG_REQUEST_FAILURE response.

A similar note should then also be appended to the end of section 5.4 -
Channel-Specific Requests.

Best regards,

denis

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 17 Nov 2004 10:06:08 -0800 (PST)

Hi,

I didn't see any responses to this.  Does anyone have any objection to
this being included?

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 17 Nov 2004 21:20:51 +0100

> I didn't see any responses to this.  Does anyone have any objection to

The proposed text is a little too verbose for my taste, but I agree
with its contents.

> >   them and sending an SSH_MSG_REQUEST_FAILURE response.

An attempt at a more concise description:

"Note that both client and server MAY send global requests, and the
 receiver MUST respond appropriately."

This sentence can be added to section "4.  Global Requests", either at
the end of the section, or at the end of the first paragraph.

I think it important to make it clear that both ends may send these
requests, if that isn't clear already. But I don't think we really
need spend a lot of words to explain why that is useful, or provide
motivating but non-standard examples.

Regards,
/Niels