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 Desktop Packages, which is subscribed to vino in Ubuntu. https://bugs.launchpad.net/bugs/1281250 Title: VNC accessible from non-linux machines only with encryption disabled Status in TigerVNC: New Status in vino: Confirmed Status in vino package in Ubuntu: Triaged Status in vino source package in Trusty: Triaged Status in vino package in Fedora: Unknown Bug description: Since a recent update, it is impossible to connect to my Ubuntu box using VNC from a Windows machine unless I disable encryption on the vino server. I tested up-to-date tightVNC client and TigerVNC client on the Windows machine, with the same result. As soon I try to connect, I receive the following error: [ 5872/ 6448] 2014-01-20 12:11:18:247 List of security type is read [ 5872/ 6448] 2014-01-20 12:11:18:247 : Security Types received (1): Unknown type (18) [ 5872/ 6448] 2014-01-20 12:11:18:247 Selecting auth-handler [ 5872/ 6448] 2014-01-20 12:11:18:247 + RemoteViewerCore. Exception: No security types supported. Server sent security types, but we do not support any of their. So it seems that the update changed the security type of vino to a new one. I searched for a way to go back to the old one (until the clients catches up) with no avail. A solution is disabling the encryption completely, by gsettings set org.gnome.Vino require-encryption false ...but this is subotpimal. Is there a way to switch the encryption back to the old one? To manage notifications about this bug go to: https://bugs.launchpad.net/tigervnc/+bug/1281250/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
