As a lurking user who hasn't (yet) contributed any code to this project, I'll risk jumping into this discussion. We use VNC for thin client and remote access terminal services. In that context, what VNC really needs is to be competitive with RDP, Citrix, PCoverIP, SunRay, etc. (none of which are open like VNC) is the following:
1. Complete session management functionality including flexible authentication, strong encryption, spawning new sessions, reconnecting to existing sessions, etc. I lump a lot of things together that do not have to be part of the RFB protocol and X server process. 2. Better graphics performance for full-motion video, low-bandwidth, etc. This does have to be part of the core code (and seems like DRC's specialty). I've used VirtualGL for visualizations, but these days flash player is a bigger deal for more people and Citrix, SunRay, and others have all developed elaborate schemes for offloading video decompression to the client. As for #1, I use a client-side script and server-side script where the convention is that the client SSHs to the server (and can therefore use whatever authentication and/or encryption is allowed & negotiated there) and the script then provides an RFB connection over stdin/stdout. It's a Unixy (or plan 9ish) approach and doesn't require the existence or use of a VNC password (which is a non-starter in this sort of environment --- especially when you don't allow reusable passwords in the first place). My only feature request to make this cleaner would be for the VNC server to support vncconnect to a Unix domain socket rather than an INET socket. The client-side script builds a local socket that connects to this ssh stdio and tells a client (vncviewer, Chicken of the VNC on Mac) to connect to it. It passes the current (or requested) screen resolution as an argument tot he server script. Again, this would be cleaner if there was something like SSH's ProxyCommand that specified a command that the viewer would use to create to connect to the server instead of an INET socket. I don't use VIA at all in this scheme. I'm happy to clean these scripts up a bit and contribute them if anybody cares, but my point is really to agree that this whole session encryption and VIA discussion doesn't actually solve any of the larger problems of secure session management. Further, I believe that most of those can be solved with more agility using external scripts rather than core C code. Cheers, Mike Fisk Los Alamos National Laboratory On Fri, Feb 11, 2011 at 2:47 PM, DRC <dcomman...@users.sourceforge.net> wrote: > On 2/11/11 3:22 PM, Robert Goley wrote: >> It does have some complications. Most software seems to use a GPL >> disclaimer/exception when using it. The libssh library is released LGPL >> though. If it can be used with GNUTLS, that should solve that issue. > > > Not really, because as mentioned previously, GnuTLS is about 1/3 as fast > as OpenSSL. Also, I don't understand the advantage of using > libssh/GnuTLS vs. just using GnuTLS like we're already doing. The only > advantage I could see to that would be in cases where there is a > restrictive firewall and only the SSH port is open. > > > I would get on board with using libssh if and only if: > > (1) It replaces GnuTLS as a way to do session encryption, not > supplements it. > > (2) It offers a fundamentally more user-friendly approach to SSH session > encryption (such as providing a single sign-on to both the SSH server > and the VNC server.) > > and > > (3) It performs as well as using the external SSH client. > > > Really, I see the -via option as a convenience feature, nothing more. > It's a way for Unix users to avoid typing the SSH forwarding command > line by hand. It's not part of a comprehensive session encryption function. > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Tigervnc-devel mailing list > Tigervnc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tigervnc-devel > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
