I've been trying to turn off encryption on vino-server in order to use one of many of the VNC clients that don't deal with TLS encryption. In the past, I've been able to start the vino-server by running by using "DISPLAY=:0 /usr/lib/vino/vino-server --sm-disable >& ~/.vino.log &" from a shell invoked with "ssh -X remotehostname".
The usual advice to turn off encryption and restart vino has reached yet another wrinkle: Upon attempting to restart vino-server (because the gsettings changes don't get re-read by vino-server except upon restart, already a problem), we now get the following messages (1) "(vino- server:21493): EggSMClient-CRITICAL **: egg_sm_client_set_mode: assertion 'global_client == NULL || global_client_mode == EGG_SM_CLIENT_MODE_DISABLED' failed" and (2) "** Message: The desktop sharing service is already running, exiting.", even after a "pkill vino". Message (1) I haven't tracked down, though another bug report: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1082182 mentions essentially the same problem, but there's no resolution. For message (2), looking at the source code, this message comes from name_lost(), which is called from: g_bus_own_name (G_BUS_TYPE_SESSION, "org.gnome.Vino", G_BUS_NAME_OWNER_FLAGS_NONE, bus_acquired, name_acquired, name_lost, &vino, NULL); Now, looking at the doc for g_bus_own_name(), from https://developer.gnome.org/gio/stable/gio-Owning-Bus-Names.html There are two ways the name_lost handler might be invoked: "You are guaranteed that one of the name_acquired_handler and name_lost_handler callbacks will be invoked after calling this function - there are three possible cases: name_lost_handler with a NULL connection (if a connection to the bus can't be made). bus_acquired_handler then name_lost_handler (if the name can't be obtained) bus_acquired_handler then name_acquired_handler (if the name was obtained)." Unfortunately the writer of this name_lost code assumed that it must be because of the second case, and completely ignored the first case (if a connection to the bus can't be made), making it hard to distinguish what's going wrong here. I know that when, for example, starting emacs from the command line over an "ssh -X" connection, I get a bunch of error messages about having trouble connecting to dbus, but it eventually starts up. Is this something similar, except that gives up immediately? I've been unable to figure out how to restart the vino-server in these cases, other than to reboot the machine. Is there a any better way to restart the vino-server? A final thought - is there any possibility of (a) turning off require encryption by default or (b) having vino-preferences set up to click off the option of requiring TLS encryption or (c) having some normal way to restart the vino-server (such as "sudo service vino restart" or something) or (d) having vino-server re-read the settings before opening a new connection or even (e) having a man page for vino-server? It's my understanding that this "require encryption" option only protects the initial handling of the password, and that all the rest of the session keystrokes and display data aren't encrypted anyway, so all these problems are the result of insisting on a change that doesn't really protect users. It's more effective to form the connection within an ssh session that would protect all the contents, password, keystroke, and display data. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1281250 Title: VNC accessible from non-linux machines only with encryption disabled To manage notifications about this bug go to: https://bugs.launchpad.net/tigervnc/+bug/1281250/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
