Re: Keepalive message per channel in SSHv2

[Simon Tatham <anakin%pobox.com@localhost>]

Pankaj Bhagra  <bhagra%cisco.com@localhost> wrote:
> This is a SSH_MSG_CHANNEL_REQUEST (0x62) message for channel id 0 (0x
> 00000000), with a string len (0x15) "keepalive%openssh.com@localhost" and have a
> want reply flag = TRUE.
[...]
> 1. Do we support per channel keepalive messages in sshv2 protocol ? I
> 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.
<anakin%pobox.com@localhost>    I prefer to think of it as good value."