Subject: Keepalive message per channel in SSHv2

From: Pankaj Bhagra <[email-masked]>
Date: Tue, 08 Jan 2002 23:59:06 -0800

Hi There,

I am not sure how to handle a keepalive message received on the client
side after the session is successfully established.

Scenario:

   Inhouse implementation of sshv2 client <----> SSH Secure Shell 2.3.0
Server

After the connection is established successfully between the inhouse
sshv2 client and SSH 2.3.0 server, the ssh client receive the following
message from the server side. 

62 00 00 00 00 00 00 00-15 6b 65 65 70 61 6c 69   b........keepali
76 65 40 6f 70 65 6e 73-73 68 2e 63 6f 6d 01      [email-masked].

This is a SSH_MSG_CHANNEL_REQUEST (0x62) message for channel id 0 (0x
00000000), with a string len (0x15) "[email-masked]" and have a
want reply flag = TRUE. 

I have couple of questions related to this message:

1. Do we support per channel keepalive messages in sshv2 protocol ? I
couldn't find this specified in ietf drafts. any pointers ??

2. How to handle this request ?

3. To me this message is not from the SO_KEEPALIVE, if the above said is
true I couldn't find the generation of the message in the 2.3 code base,
could anyone xplain what is happening here. Is it mandated/suggested by
the protocol to support 2 kinds of keepalive, one at TCP level and
another at per channel ??

comments ??

later,
pankaj

---

From: Markus Friedl <[email-masked]>
Date: Wed, 9 Jan 2002 10:07:45 +0100

> couldn't find this specified in ietf drafts. any pointers ??

no.

> 2. How to handle this request ?

send a request failed message back if 'want reply' is true.

> true I couldn't find the generation of the message in the 2.3 code base,

it's an experimental feature in openssh.

> another at per channel ??

no.

---

From: Simon Tatham <[email-masked]>
Date: Wed, 09 Jan 2002 09:17:19 +0000

> 00000000), with a string len (0x15) "[email-masked]" and have a
[...]
> couldn't find this specified in ietf drafts. any pointers ??

The idea is that you _don't_ support it. From your client's point of
view - and, I believe, even from the OpenSSH client's point of view
- this is an unsupported channel request. Hence you send
SSH_MSG_CHANNEL_FAILURE, indicating that you were unable to perform
whatever function the message was requesting. Even clients that
don't understand it should do this.

And this is sufficient to reassure the server that the client is
still alive - if it sees SSH_MSG_CHANNEL_FAILURE, the client must
still be around to have sent it.

> 2. How to handle this request ?

The same way you would handle any other unsupported channel request
with want_reply set to TRUE: you send SSH_MSG_CHANNEL_FAILURE.

> Is it mandated/suggested by the protocol to support 2 kinds of
> keepalive, one at TCP level and another at per channel ??

It doesn't have to be mandated in the protocol; this is a protocol
extension on the part of the OpenSSH people, cleverly designed so
that any standards-compliant client should work correctly with it.

It's not an unmixed blessing; an SSH session without protocol-level
keepalives might survive a very long (hours or days) network outage
if no data transfer was attempted in the meantime, but this sort of
keepalive might actually _shorten_ the session lifetime in this sort
of situation. On the other hand, it would help to remind some types
of connection-aware firewall that the connection is still alive.

(Given all this I'm not entirely sure why it's sensible to run it at
the server end as a matter of sysadmin policy, instead of running it
at the client end and allowing individual users to adapt it to their
needs. Also I have no idea why it's an SSH_MSG_CHANNEL_REQUEST
instead of an SSH_MSG_GLOBAL_REQUEST, since there's nothing actually
channel-specific about it and the latter would even work if no
channels happened to be open at the time; but *shrug*, that's not my
problem :-)

Cheers,
Simon
-- 
Simon Tatham         "You may call that a cheap shot.
<[email-masked]>    I prefer to think of it as good value."