Re: [rfbhackers] using SSH2

[Andrew v. d. S. <aj...@gr...>]

It'd be better if we tracked IETF's secsh rather than ssh2 per se. secsh is
shaking out the protocol bugs of the ssh2 protocol, and will be a better
target as it matures.

Also, secsh/ssh2 is fairly large, which is a consideration for smaller
clients. I wanted something small, like AES for inbuilt encryption and SRP
for authentication so that the smallest clients wouldn't overly suffer from
huge library imports and associated licensing issues. Saying that however,
secsh has extreme merit for the purposes that I wanted SRP and AES and
channels.

Realistically, RFB 4.0 requires a new decoder, so the compatibility issue is
somewhat moot. I was hoping that RFB 3.x code, once triggered by the RFB 4.x
would remain interoperable. I have tried where I can to not change the
semantics of the message, only the way it is delivered.

However, you are right, if we go to secsh for the transport (and I like the
idea of using its channels), we can't be on port 5900 and allow RFB 3.x
clients to connect as the server gets to talk first. We'd have to choose
another port. We could have a fall through that starts the negotiation after
RFB 4.x is selected, like we do at the moment, to fix that, but we wouldn't
be a pure secsh enabled protocol.

Prioritization is a method of fixing interactivity problems. I wanted to
ensure that all packets are not too large, and that things like file
transfers were done when literally nothing else was happening so as to not
freeze the interface. We could just make it part of the protocol that
requires clients and servers to play well, just as in the cooperative
multi-tasking days. I'd prefer prioritization to be left in or added
somehow.

Andrew

----- Original Message -----
From: "Michael Ossmann" <mic...@al...>
To: <sec...@li...>
Sent: Thursday, January 17, 2002 10:27 AM
Subject: [rfbhackers] using SSH2


> I'd like to discuss the possibility of using SSH2 as the lower layers of
> RFB4.  I wouldn't be surprised if this has been discussed already, but,
> if so, I'd like to hear the reasons that this direction has not been
> pursued.
>
> SSH2 is an extensible protocol which includes authentication,
> encryption, and channel multiplexing, all features which are essential
> parts of the RFB4 draft.  SSH1 and SSH2 are already popular tools among
> VNC integrators for these very capabilities but are generally integrated
> with VNC by using SSH's TCP port forwarding capabilities.  It is also
> possible to use SSH2 channels directly, avoiding the security and
> administration problems inherent in port forwarding.
>
> The pros that I see are:
>   - The design work of these layers is already done.
>   - SSH2 is further along the standards track.
>   - We gain the benefit of the many eyeballs that are looking at SSH2.
>   - RFB4 protocol implementation becomes easier because we can reuse
>     existing open source SSH2 code or even integrate with complete SSH2
>     products (such as OpenSSH's subsystem feature).
>
> The cons:
>   - Backwards compatibility with RFB3 becomes more difficult.
>   - I haven't looked into channel prioritization, but it might be a
>     problem.
>
> Thoughts?
>
> By the way, I'm currently making my way through the draft and so far I'm
> very impressed.  It is exactly the direction that I had hoped RFB would
> go.