On 16/02/11 04:11, Martin Koegler wrote: > On Tue, Feb 15, 2011 at 08:22:15AM -0700, Mike Fisk wrote: >> 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. >> >> 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. That shouldn't be hard to add, as far as the code is concerned it's just a 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. > > Making the vncviewer ssh into the server as the user, detecting all > running VNC servers of the user and finally let the user select to > connect to one instance or start a new session: I'm really missing > such a feature [I had done such experiments too: > http://e9925248.users.sourceforge.net/vnctermserv/]. > > The challenge for such script solution is, that they are complicated > on the windows client side [no scripting, no ssh]. I originally started down the same path, but the complexities lead me to write a more traditional client/server solution. Cheers Antoine > > Regards, > Martin Kögler ------------------------------------------------------------------------------ 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
