From: Daniel P. B. <ber...@re...> - 2007-08-29 15:40:28
|
On Wed, Aug 29, 2007 at 08:48:47AM -0300, Jonh Wendell wrote: > Em Ter, 2007-08-28 às 22:39 +0100, Daniel P. Berrange escreveu: > > We currently have two APIs for openning connections > > > > vnc_display_open_fd - takes a pre-opened file handle > > vnc_display_open_host - takes hostname & servicename (aka port) > > > > Another pretty common way to access VNC servers is by tunnelling them over > > SSH. Now obviously any client apps could implement this themselves by forking > > ssh and then calling vnc_display_open_fd. I don't particularly want to have > > to implement this multiple times in each app though. So what do people think > > about having an explicit API for openning an SSH tunnelled connection, and > > even an arbitrary 'external' tunnel script (cf CVS 'ext' method). > > > > > > vnc_display_open_ssh_tunnel(VncDisplay *d, const char *user, const char *host, const char *port) > > vnc_display_open_ext_tunnel(VncDisplay *d, const char *script); > > > > Or just one todo both .... > > > > vnc_display_open_ext_tunnel(VncDisplay *d, const char **argv); > > > > Attaching a crude impl of the SSH tunnel impl > > > > Regards, > > Dan. > > Hi, Dan. > > Really this is a great feature. I never connected into a machine via ssh > tunelled connection. So, some questions: > > - Doesn't it need a password? Yes & no. Personally I'd just define it as supported if-only-if you have setup SSH keys (and SSH agent to avoid entering passphrase). Feeding an SSH password prompt back up to the user is really painful. > - The port parameter is the port of VNC or port of SSH? Of the VNC server on the remote host. > - What about use the same api (vnc_display_open_host), just adding a > boolean parameter to indicate if the connection is via ssh or not? I think we at very least ned a username for SSH, possibly also an SSH port number. Adding extra APIs in the vnc_display module doesn't cause any significant code duplication, because ultimately they all feed into the same GVNC calls where most of the setup code is. So I prefer to have explicit APIs for each open. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| |